[Geoserver-devel] [JIRA] (GEOS-10377) Layers and Layer Groups get default abstract in capabilities document when none set in configuration.

[Justin Deoliveira (JIRA)]

Justin Deoliveira ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3Abf34147d-5afe-4819-a12e-2d248b4c0a47
 ) *created* an issue

GeoServer ( 
https://osgeo-org.atlassian.net/browse/GEOS?atlOrigin=eyJpIjoiZWI0M2RmMWEzZGJlNDBiZTllNDFkMWIwY2Q2MWM5YTkiLCJwIjoiaiJ9
 ) / Bug ( 
https://osgeo-org.atlassian.net/browse/GEOS-10377?atlOrigin=eyJpIjoiZWI0M2RmMWEzZGJlNDBiZTllNDFkMWIwY2Q2MWM5YTkiLCJwIjoiaiJ9
 ) GEOS-10377 ( 
https://osgeo-org.atlassian.net/browse/GEOS-10377?atlOrigin=eyJpIjoiZWI0M2RmMWEzZGJlNDBiZTllNDFkMWIwY2Q2MWM5YTkiLCJwIjoiaiJ9
 ) Layers and Layer Groups get default abstract in capabilities document when 
none set in configuration. ( 
https://osgeo-org.atlassian.net/browse/GEOS-10377?atlOrigin=eyJpIjoiZWI0M2RmMWEzZGJlNDBiZTllNDFkMWIwY2Q2MWM5YTkiLCJwIjoiaiJ9
 )

Issue Type: Bug Assignee: Justin Deoliveira ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3Abf34147d-5afe-4819-a12e-2d248b4c0a47
 ) Components: WMS Created: 01/Feb/22 11:31 PM Priority: Medium Reporter: 
Justin Deoliveira ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3Abf34147d-5afe-4819-a12e-2d248b4c0a47
 )

Recent builds have made it so that Layers receive a default abstract of the 
form “Layer-group …”, when none is set in the configuration. Previous behaviour 
was to produce an empty abstract element.

( 
https://osgeo-org.atlassian.net/browse/GEOS-10377#add-comment?atlOrigin=eyJpIjoiZWI0M2RmMWEzZGJlNDBiZTllNDFkMWIwY2Q2MWM5YTkiLCJwIjoiaiJ9
 ) Add Comment ( 
https://osgeo-org.atlassian.net/browse/GEOS-10377#add-comment?atlOrigin=eyJpIjoiZWI0M2RmMWEzZGJlNDBiZTllNDFkMWIwY2Q2MWM5YTkiLCJwIjoiaiJ9
 )

Get Jira notifications on your phone! Download the Jira Cloud app for Android ( 
https://play.google.com/store/apps/details?id=com.atlassian.android.jira.core=utm_source%3DNotificationLink%26utm_medium%3DEmail
 ) or iOS ( 
https://itunes.apple.com/app/apple-store/id1006972087?pt=696495=EmailNotificationLink=8
 ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100190- 
sha1:a87da57 )
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Default value for Layer abstracts

[Justin Deoliveira]

Thanks folks!

You bet, happy to submit a PR, just wanted to confirm that it's not
intended behaviour before proceeding. Stay tuned.

On Tue., Feb. 1, 2022, 1:17 a.m. Andrea Aime, <
andrea.a...@geosolutionsgroup.com> wrote:

> On Mon, Jan 31, 2022 at 6:06 PM Justin Deoliveira 
> wrote:
>
>> Howdy folks,
>>
>
> Hey Justin, nice to hear from you!
>
>
>> I guess my ultimate question is whether this is desirable behavior? I am
>> thinking an abstract referencing "Layer-Group" in the cases where it's not
>> a layer group is perhaps an oversight.
>>
>
> Yep, looks bad for layers, and even for layer groups. Any chance you have
> time for a PR?
>
> Cheers
> Andrea
>
> ==
>
> GeoServer Professional Services from the experts!
>
> Visit http://bit.ly/gs-services-us for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions Group
> phone: +39 0584 962313
>
> fax: +39 0584 1660272
>
> mob:   +39  333 8128928
>
> https://www.geosolutionsgroup.com/
>
> http://twitter.com/geosolutions_it
>
> ---
>
> Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE
> 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si
> precisa che ogni circostanza inerente alla presente email (il suo
> contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è
> riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il
> messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra
> operazione è illecita. Le sarei comunque grato se potesse darmene notizia.
>
> This email is intended only for the person or entity to which it is
> addressed and may contain information that is privileged, confidential or
> otherwise protected from disclosure. We remind that - as provided by
> European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
> e-mail or the information herein by anyone other than the intended
> recipient is prohibited. If you have received this email by mistake, please
> notify us immediately by telephone or e-mail
>
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Default value for Layer abstracts

[Justin Deoliveira]

Thanks Gabriel, nice to hear from you too!

You're right in that for layer groups this has always been the behavior.
What I think happened in the recent i18n refactor was that some code was
refactored to share the encoding of the title and abstract for LayerInfo
and LayerGroupInfo, and in doing so changed the behavior for single layers
(non layer-group). I believe this was the change in that commit that did it:

https://github.com/geoserver/geoserver/commit/3ea0b9817a4f1264c815d874ae612bf5e6d6fea4#diff-ce88fe929a6cf41c007f131c83eae16caedb0e849ccc0ccfe2ddcec7bdaead3cL1003


On Mon, Jan 31, 2022 at 11:33 AM Gabriel Roldan 
wrote:

> Hey man, nice to hear from you.
>
> That seems strange actually, but couldn't track down when it was added,
> it's already there at the first
> git commit (44bacafcf1) in June 2011, so it's from the svn days.
>
> Wait, yeah, been like that since 2007 at least:
> https://github.com/geoserver/geoserver-history/commit/9ab43af58a#diff-26d7a2ab35bebf3788e69ccb99b9722baf3a0fdb72f65278c620b6a80803dc49R964
>
> That said, it makes all sense to me to remove it and emit an empty element
> instead.
>
> Cheers!
>
> On Mon, 31 Jan 2022 at 14:07, Justin Deoliveira 
> wrote:
>
>> Howdy folks,
>>
>> First off amazing job on the project, great to see GeoServer thriving and
>> be such a robust and stable tool, kudos to all of the core developers for
>> their hard work.
>>
>> I have a question about a change that I am seeing after upgrading a
>> Geoserver instance from a 2.18.x to the latest stable 2.20.x, with regards
>> to layer abstracts in the WMS capabilities document. I wanted to check here
>> whether it's considered a bug or not before I file a ticket, or work on a
>> patch. The issue in question I believe traces back to the recent work done
>> to allow for i18n of the capabilities document:
>>
>> - Pre-change, when a layer had no abstract the element would show up as
>> empty in the capabilities document.
>> - Post-change, the abstract gets a default value of "Layer-Group type
>> layer: "
>>
>> I guess my ultimate question is whether this is desirable behavior? I am
>> thinking an abstract referencing "Layer-Group" in the cases where it's not
>> a layer group is perhaps an oversight.
>>
>> The bigger question is whether it's desirable to have a fallback value at
>> all. In the case of the project I am working on there is an application
>> that displays those abstracts to the user, which after the upgrade started
>> to get a bit confusing with all of the default abstracts in there. I
>> imagine there are GIS clients and web applications powered by GeoServer
>> that do the same, which is why I wanted to ask.
>>
>> Thanks GeoServer crew!
>>
>> Justin
>>
>> ___
>> Geoserver-devel mailing list
>> Geoserver-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>
>
>
> --
> Gabriel Roldán
>
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] Default value for Layer abstracts

[Justin Deoliveira]

Howdy folks,

First off amazing job on the project, great to see GeoServer thriving and
be such a robust and stable tool, kudos to all of the core developers for
their hard work.

I have a question about a change that I am seeing after upgrading a
Geoserver instance from a 2.18.x to the latest stable 2.20.x, with regards
to layer abstracts in the WMS capabilities document. I wanted to check here
whether it's considered a bug or not before I file a ticket, or work on a
patch. The issue in question I believe traces back to the recent work done
to allow for i18n of the capabilities document:

- Pre-change, when a layer had no abstract the element would show up as
empty in the capabilities document.
- Post-change, the abstract gets a default value of "Layer-Group type
layer: "

I guess my ultimate question is whether this is desirable behavior? I am
thinking an abstract referencing "Layer-Group" in the cases where it's not
a layer group is perhaps an oversight.

The bigger question is whether it's desirable to have a fallback value at
all. In the case of the project I am working on there is an application
that displays those abstracts to the user, which after the upgrade started
to get a bit confusing with all of the default abstracts in there. I
imagine there are GIS clients and web applications powered by GeoServer
that do the same, which is why I wanted to ask.

Thanks GeoServer crew!

Justin
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Possible to financially sponsor extension-support for Python/WPS plugin?

[Justin Deoliveira]

Hey folks, chiming in here as I am the original author of the module in
question. I do freelance GeoServer consulting work so I'd be happy to
engage with you Patrick to get this work done. As Andrea mentioned the code
in question here is in a community module which normally doesn't require a
formal proposal to do work in, at least not at this time.

If you're game Patrick I suggest we work out the details offline and then
update the developer list with a plan of sorts, elicit feedback, etc...

That said if the PMC and core developers have an interest in tackling this
work as a collective group (similar to other initiatives in the past) I
would happily step aside and allow things to go that route.

On Fri, Feb 15, 2019 at 10:00 AM Andrea Aime 
wrote:

> On Fri, Feb 15, 2019 at 5:50 PM Jody Garnett 
> wrote:
>
>> That would be an appropriate use of a GSIP:
>>
>> Thoughts:
>> - We do recommend writing a proposal to verify an approach prior to
>> starting work, in the past when the idea was associated with pending
>> funding this was made note of (so folks do not get their hopes up).
>> - This a subtle trap where if a GSIP for a good idea is proposed there
>> can be a temptation to hang back and let someone else pay for it
>> - In geotools we use proposals to explore an idea and also secure a
>> commitment for each task (to ensure a contributor is in position to do the
>> work, you could do something similar with funding targets).
>>
>
> Jody, I would discourage usage of proposals this way, people have already
> tried to do that in the hopes of getting an idea "accepted" and then
> pretending to see it implemented only because of that, without funds.
> Proposals were created exactly to verify that the activity had enough
> resources behind to make it happen.
>
> Here we are starting the opposite, someone is willing to sponsor, and the
> module is a community one, thus unsupported, a part of the codebase
> where no proposals are needed.
>
>
>> One thing we experimented with last year was accepting some sponsorship
>> for a feature (improved SLD interoperability between QGIS and GeoServer)
>> and then requesting proposals. You may wish to look at how this is turning
>> out and consider if the approach would work in your case?
>>
>
> Yep, that would work... but in that case we started with a given amount of
> money (which was not enough to do the full job) and then the GeoServer PSC
> and others pitched in to reach
> a threshold that made it doable.
> I believe the blockers in this case are two:
>
>- Need to find someone familiar enough with the module to do the job
>- Need to figure out how much money would be needed (or someone starts
>with a blind donation to get things started like in the QGIS raster
>symbolizer export case)
>
> Cheers
> Andrea
>
> ==
>
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf
> Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa
> (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549
> http://www.geo-solutions.it http://twitter.com/geosolutions_it
> --- *Con riferimento
> alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 -
> Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni
> circostanza inerente alla presente email (il suo contenuto, gli eventuali
> allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i
> destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per
> errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
> sarei comunque grato se potesse darmene notizia. This email is intended
> only for the person or entity to which it is addressed and may contain
> information that is privileged, confidential or otherwise protected from
> disclosure. We remind that - as provided by European Regulation 2016/679
> “GDPR” - copying, dissemination or use of this e-mail or the information
> herein by anyone other than the intended recipient is prohibited. If you
> have received this email by mistake, please notify us immediately by
> telephone or e-mail.*
> ___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Mosaics with postgis raster and time

[Justin Deoliveira]

Ahh ok, cool I'll look into that a bit more closely. I've got the code to
the point where basic mosaicing is working and it can handle all of the
time series stuff and now am going to circle back and clean a few things
up.

I'll definitely put this into a community module. I've already had someone
from the community reach out expressing interest in the code. I'll start a
separate through on geotools-devel for that soon.

Thanks again for the all of the feedback and help!

On Thu, Nov 29, 2018 at 9:32 AM Andrea Aime 
wrote:

> On Thu, Nov 29, 2018 at 5:27 PM Justin Deoliveira 
> wrote:
>
>> Thanks Andrea.
>>
>> So yeah, re managing the connections the current implementation I have
>> allows you to specify the the connection params directly, ie the reader
>> would manage it's own connection pool. But also allow for grabbing the
>> connection from JNDI. Basically what the JDBC datastores do. For the
>> project I am going to deploy this in the JNDI option will be what we use to
>> optimize the connection usage.
>>
>> Passing in a connection pool via a hint would also work nicely, basically
>> the same way it works when an ExecutorService is passed in. I am not sure
>> what the GeoServer side of that looks like though...
>>
>
> Yeah, that would need to be "invented". Like some setting to pick the
> connection pool from some other existing store for example.
> To be honest, I have been itching to add to GeoServer connection pool as
> first class catalog objects that can then be passed around to various
> stores, but never got around to do it.
>
>
>> It would also be nice to utilize the apis in coverage for serving up
>> multiple coverages from a single reader. I went down that route but was a
>> little confused as to how well this is supported.
>> AbstractGridCoverage2DReader seems to be written to maintain state about
>> multiple coverages which is good. But on the GeoServer side I am unsure if
>> the relationship between coverage store and coverage has to be 1:1... has
>> this changed at all recently? Or maybe it was always possible... not sure.
>> Anyways, if it was possible to use a single reader instance for multiple
>> coverages from the same coverage store storing a connection pool in that
>> reader would also be a good way to share the connection pool.
>>
>
> We do manage multilple rasters per reader with mosaic and netcdf without
> particular problems. If memory serves me right, ResourcePool wraps the
> readers with a renaming class that gives the rest of the code the illusion
> there is a single raster in the reader.
>
> Cheers
> Andrea
>
> ==
>
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf
> Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa
> (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549
> http://www.geo-solutions.it http://twitter.com/geosolutions_it
> --- *Con riferimento
> alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 -
> Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni
> circostanza inerente alla presente email (il suo contenuto, gli eventuali
> allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i
> destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per
> errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
> sarei comunque grato se potesse darmene notizia. This email is intended
> only for the person or entity to which it is addressed and may contain
> information that is privileged, confidential or otherwise protected from
> disclosure. We remind that - as provided by European Regulation 2016/679
> “GDPR” - copying, dissemination or use of this e-mail or the information
> herein by anyone other than the intended recipient is prohibited. If you
> have received this email by mistake, please notify us immediately by
> telephone or e-mail.*
>
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Mosaics with postgis raster and time

[Justin Deoliveira]

Thanks Andrea.

So yeah, re managing the connections the current implementation I have
allows you to specify the the connection params directly, ie the reader
would manage it's own connection pool. But also allow for grabbing the
connection from JNDI. Basically what the JDBC datastores do. For the
project I am going to deploy this in the JNDI option will be what we use to
optimize the connection usage.

Passing in a connection pool via a hint would also work nicely, basically
the same way it works when an ExecutorService is passed in. I am not sure
what the GeoServer side of that looks like though...

It would also be nice to utilize the apis in coverage for serving up
multiple coverages from a single reader. I went down that route but was a
little confused as to how well this is supported.
AbstractGridCoverage2DReader seems to be written to maintain state about
multiple coverages which is good. But on the GeoServer side I am unsure if
the relationship between coverage store and coverage has to be 1:1... has
this changed at all recently? Or maybe it was always possible... not sure.
Anyways, if it was possible to use a single reader instance for multiple
coverages from the same coverage store storing a connection pool in that
reader would also be a good way to share the connection pool.

Interested to hear your thoughts.

-Justin

On Thu, Nov 29, 2018 at 7:51 AM Andrea Aime 
wrote:

> Hi Justin,
> makes sense to me, thanks for keeping up up to date. The code seems
> interesting, what about putting it in a community module?
>
> Wondering how you'll manage the connections and their eventual pooling,
> Gabriel pulled some trick with the SDE to make it share
> with the store, could be interesting to have the same, e.g., the ability
> to pass a pool as parts of the reader hints maybe.
>
> Cheers
> Andrea
>
>
> On Tue, Nov 27, 2018 at 11:44 PM Justin Deoliveira 
> wrote:
>
>> Hey folks, just thought I would update on this. So after looking into the
>> imagemosaic jdbc plugin we decided to go with a different approach. Once I
>> started looking into what the effort of updating the imagemosaic jdbc stuff
>> it seemed like much less effort to just implement reader dedicated to
>> postgis rasters. Also much simpler in terms of configuration since it won't
>> require a bunch of manual mapping, etc... so I've embarked on that
>> approach.
>>
>> The project will be happy to donate all of that code to GeoTools if
>> people find it useful.
>>
>> Thanks again to Andrea and Christian for all the feedback.
>>
>> On Mon, Nov 19, 2018 at 12:21 PM Justin Deoliveira 
>> wrote:
>>
>>> Ok cool, sorry I didn't see that in the docs. Thanks Andrea, that's very
>>> helpful.
>>>
>>> On Mon, Nov 19, 2018 at 12:13 PM Andrea Aime <
>>> andrea.a...@geo-solutions.it> wrote:
>>>
>>>> On Mon, Nov 19, 2018 at 8:09 PM Justin Deoliveira 
>>>> wrote:
>>>>
>>>>> Thanks for the info Christian, I assume you replied directly to me by
>>>>> accident so re-including the list.
>>>>>
>>>>> My initial thought was that there would be just one "time column"
>>>>> composed of discrete timestamps, or at least that is the use case I
>>>>> currently have. I am also kind of going off of what the core mosaic reader
>>>>> does and unless I am mistaken (which is very possible to someone please 
>>>>> let
>>>>> me know :) ) there is just a single time attribute for each entry of the
>>>>> mosaic and you can specify the time resolution to essentially create an
>>>>> interval.
>>>>>
>>>>> That said a start/end date also makes sense to me. I haven't started
>>>>> digging into the code yet but I will keep this in mind in the approach and
>>>>> perhaps add support for both modes if people think that makes sense?
>>>>>
>>>>
>>>> The image mosaic works either off one timestamp column, for instant
>>>> time support, or two time columns, begin and end, for time range support.
>>>>
>>>> Cheers
>>>> Andrea
>>>>
>>>> ==
>>>>
>>>> GeoServer Professional Services from the experts! Visit
>>>> http://goo.gl/it488V for more information. == Ing. Andrea Aime
>>>> @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054
>>>> Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339
>>>> 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it
>>>> --

Re: [Geoserver-devel] Mosaics with postgis raster and time

[Justin Deoliveira]

Hey folks, just thought I would update on this. So after looking into the
imagemosaic jdbc plugin we decided to go with a different approach. Once I
started looking into what the effort of updating the imagemosaic jdbc stuff
it seemed like much less effort to just implement reader dedicated to
postgis rasters. Also much simpler in terms of configuration since it won't
require a bunch of manual mapping, etc... so I've embarked on that
approach.

The project will be happy to donate all of that code to GeoTools if people
find it useful.

Thanks again to Andrea and Christian for all the feedback.

On Mon, Nov 19, 2018 at 12:21 PM Justin Deoliveira 
wrote:

> Ok cool, sorry I didn't see that in the docs. Thanks Andrea, that's very
> helpful.
>
> On Mon, Nov 19, 2018 at 12:13 PM Andrea Aime 
> wrote:
>
>> On Mon, Nov 19, 2018 at 8:09 PM Justin Deoliveira 
>> wrote:
>>
>>> Thanks for the info Christian, I assume you replied directly to me by
>>> accident so re-including the list.
>>>
>>> My initial thought was that there would be just one "time column"
>>> composed of discrete timestamps, or at least that is the use case I
>>> currently have. I am also kind of going off of what the core mosaic reader
>>> does and unless I am mistaken (which is very possible to someone please let
>>> me know :) ) there is just a single time attribute for each entry of the
>>> mosaic and you can specify the time resolution to essentially create an
>>> interval.
>>>
>>> That said a start/end date also makes sense to me. I haven't started
>>> digging into the code yet but I will keep this in mind in the approach and
>>> perhaps add support for both modes if people think that makes sense?
>>>
>>
>> The image mosaic works either off one timestamp column, for instant time
>> support, or two time columns, begin and end, for time range support.
>>
>> Cheers
>> Andrea
>>
>> ==
>>
>> GeoServer Professional Services from the experts! Visit
>> http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf
>> Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa
>> (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549
>> http://www.geo-solutions.it http://twitter.com/geosolutions_it
>> --- *Con riferimento
>> alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 -
>> Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni
>> circostanza inerente alla presente email (il suo contenuto, gli eventuali
>> allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i
>> destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per
>> errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
>> sarei comunque grato se potesse darmene notizia. This email is intended
>> only for the person or entity to which it is addressed and may contain
>> information that is privileged, confidential or otherwise protected from
>> disclosure. We remind that - as provided by European Regulation 2016/679
>> “GDPR” - copying, dissemination or use of this e-mail or the information
>> herein by anyone other than the intended recipient is prohibited. If you
>> have received this email by mistake, please notify us immediately by
>> telephone or e-mail.*
>>
>
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Mosaics with postgis raster and time

[Justin Deoliveira]

Ok cool, sorry I didn't see that in the docs. Thanks Andrea, that's very
helpful.

On Mon, Nov 19, 2018 at 12:13 PM Andrea Aime 
wrote:

> On Mon, Nov 19, 2018 at 8:09 PM Justin Deoliveira 
> wrote:
>
>> Thanks for the info Christian, I assume you replied directly to me by
>> accident so re-including the list.
>>
>> My initial thought was that there would be just one "time column"
>> composed of discrete timestamps, or at least that is the use case I
>> currently have. I am also kind of going off of what the core mosaic reader
>> does and unless I am mistaken (which is very possible to someone please let
>> me know :) ) there is just a single time attribute for each entry of the
>> mosaic and you can specify the time resolution to essentially create an
>> interval.
>>
>> That said a start/end date also makes sense to me. I haven't started
>> digging into the code yet but I will keep this in mind in the approach and
>> perhaps add support for both modes if people think that makes sense?
>>
>
> The image mosaic works either off one timestamp column, for instant time
> support, or two time columns, begin and end, for time range support.
>
> Cheers
> Andrea
>
> ==
>
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf
> Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa
> (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549
> http://www.geo-solutions.it http://twitter.com/geosolutions_it
> --- *Con riferimento
> alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 -
> Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni
> circostanza inerente alla presente email (il suo contenuto, gli eventuali
> allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i
> destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per
> errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
> sarei comunque grato se potesse darmene notizia. This email is intended
> only for the person or entity to which it is addressed and may contain
> information that is privileged, confidential or otherwise protected from
> disclosure. We remind that - as provided by European Regulation 2016/679
> “GDPR” - copying, dissemination or use of this e-mail or the information
> herein by anyone other than the intended recipient is prohibited. If you
> have received this email by mistake, please notify us immediately by
> telephone or e-mail.*
>
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Mosaics with postgis raster and time

[Justin Deoliveira]

Thanks for the info Christian, I assume you replied directly to me by
accident so re-including the list.

My initial thought was that there would be just one "time column" composed
of discrete timestamps, or at least that is the use case I currently have.
I am also kind of going off of what the core mosaic reader does and unless
I am mistaken (which is very possible to someone please let me know :) )
there is just a single time attribute for each entry of the mosaic and you
can specify the time resolution to essentially create an interval.

That said a start/end date also makes sense to me. I haven't started
digging into the code yet but I will keep this in mind in the approach and
perhaps add support for both modes if people think that makes sense?

Thanks!



On Sun, Nov 18, 2018 at 10:09 AM Christian Mueller <
christian.muel...@os-solutions.at> wrote:

> Hi Justin and Andrea
>
> Sorry for the late reply. IMHO it would make sense to add the business
> time support as described in SQL 2011.  At the end of the day you need 2
> attrilbutes of type DATE, one for the start and one for the end. (The open
> end may be something like 2999-12-31).  The important issue is that the
> start date is included in the time period and the end date is NOT included.
>
> I know about support in DB2 and Oracle, Postgres provides an intervall
> data type, and I think Andrea mentioned MS Sqlserver some time ago.
>
> Just my 2 cents.
>
>
>
>
>
> On Sun, Nov 18, 2018 at 6:04 PM Christian Mueller <
> christian.muel...@os-solutions.at> wrote:
>
>> Hi Justin and Adrea
>>
>> Sorry for the late
>>
>>
>> On Wed, Nov 14, 2018 at 9:14 PM Justin Deoliveira 
>> wrote:
>>
>>> Ok great. Thanks for the info Andrea!
>>>
>>> On Wed, Nov 14, 2018, 11:57 AM Andrea Aime >> wrote:
>>>
>>>> On Tue, Nov 13, 2018 at 5:30 PM Justin Deoliveira 
>>>> wrote:
>>>>
>>>>> One thing you could help me with is a quick sanity check on the
>>>>> approach. I was basically just planning to add a "timeAttribute" element 
>>>>> to
>>>>> the mapping file, and when present have the coverage reader declare the
>>>>> appropriate metadata in support of the time domain. Let me know if you
>>>>> think that is the wrong way to go.
>>>>>
>>>>
>>>> Sounds reasonable to me. The situation now is a bit fluid, there are
>>>> some methods accessing dimension domains
>>>> that use the StructuredCoverageGridReader interface to allow for
>>>> certain database optimizations, but the metadata
>>>> entries are still supported and in some cases they are the only ones
>>>> still used.
>>>>
>>>> Some examples of both approaches in this class:
>>>>
>>>> https://github.com/geoserver/geoserver/blob/2e681e2a74f0754e294bbb481ecf7ad33552b3e6/src/main/src/main/java/org/geoserver/catalog/util/ReaderDimensionsAccessor.java
>>>>
>>>> Cheers
>>>> Andrea
>>>>
>>>> ==
>>>>
>>>> GeoServer Professional Services from the experts! Visit
>>>> http://goo.gl/it488V for more information. == Ing. Andrea Aime
>>>> @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054
>>>> Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339
>>>> 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it
>>>> --- *Con
>>>> riferimento alla normativa sul trattamento dei dati personali (Reg. UE
>>>> 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si
>>>> precisa che ogni circostanza inerente alla presente email (il suo
>>>> contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è
>>>> riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il
>>>> messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra
>>>> operazione è illecita. Le sarei comunque grato se potesse darmene notizia.
>>>> This email is intended only for the person or entity to which it is
>>>> addressed and may contain information that is privileged, confidential or
>>>> otherwise protected from disclosure. We remind that - as provided by
>>>> European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
>>>> e-mail or the information herein by anyone other than the intended
>>>> recipient is prohibited. If you have received this email by mistake, please
>>>> notify us immediately by telephone or e-mail.*
>>>>
>>>
>>
>> --
>> DI Christian Mueller MSc (GIS), MSc (IT-Security)
>> OSS Open Source Solutions GmbH
>>
>>
>
> --
> DI Christian Mueller MSc (GIS), MSc (IT-Security)
> OSS Open Source Solutions GmbH
>
>
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Mosaics with postgis raster and time

[Justin Deoliveira]

Ok great. Thanks for the info Andrea!

On Wed, Nov 14, 2018, 11:57 AM Andrea Aime  On Tue, Nov 13, 2018 at 5:30 PM Justin Deoliveira 
> wrote:
>
>> One thing you could help me with is a quick sanity check on the approach.
>> I was basically just planning to add a "timeAttribute" element to the
>> mapping file, and when present have the coverage reader declare the
>> appropriate metadata in support of the time domain. Let me know if you
>> think that is the wrong way to go.
>>
>
> Sounds reasonable to me. The situation now is a bit fluid, there are some
> methods accessing dimension domains
> that use the StructuredCoverageGridReader interface to allow for certain
> database optimizations, but the metadata
> entries are still supported and in some cases they are the only ones still
> used.
>
> Some examples of both approaches in this class:
>
> https://github.com/geoserver/geoserver/blob/2e681e2a74f0754e294bbb481ecf7ad33552b3e6/src/main/src/main/java/org/geoserver/catalog/util/ReaderDimensionsAccessor.java
>
> Cheers
> Andrea
>
> ==
>
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf
> Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa
> (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549
> http://www.geo-solutions.it http://twitter.com/geosolutions_it
> --- *Con riferimento
> alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 -
> Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni
> circostanza inerente alla presente email (il suo contenuto, gli eventuali
> allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i
> destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per
> errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
> sarei comunque grato se potesse darmene notizia. This email is intended
> only for the person or entity to which it is addressed and may contain
> information that is privileged, confidential or otherwise protected from
> disclosure. We remind that - as provided by European Regulation 2016/679
> “GDPR” - copying, dissemination or use of this e-mail or the information
> herein by anyone other than the intended recipient is prohibited. If you
> have received this email by mistake, please notify us immediately by
> telephone or e-mail.*
>
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Mosaics with postgis raster and time

[Justin Deoliveira]

Thanks Christian If anyone understands the issue with lack of time to put
toward open source stuff it's me :) I hope to get back to it someday...
maybe when my kids are out of the house ;)

One thing you could help me with is a quick sanity check on the approach. I
was basically just planning to add a "timeAttribute" element to the mapping
file, and when present have the coverage reader declare the appropriate
metadata in support of the time domain. Let me know if you think that is
the wrong way to go.

Thanks!

On Tue, Nov 13, 2018 at 12:18 AM Christian Mueller <
christian.muel...@os-solutions.at> wrote:

> Hi Andreas and Justin
>
> Nice to talk with you again. At the time I developed the ImageMosaic-Jdbc
> module I was focused on Geotools and I did not know about the relation to
> Geoserver. Maybe my fault. In the meantime it is a problem of time, no
> chance for me to invest further time. I know that this module is not a
> "smooth" solution.
>
> Sorry, Christian
>
> On Mon, Nov 12, 2018 at 6:51 PM Justin Deoliveira 
> wrote:
>
>> Thanks for the input Andrea. Yeah I'm a bit weary of putting time into
>> the image mosaic jdbc plugin if it's falling toward unsupported. But I
>> don't think the project scope will allow for going the route of trying to
>> update the core plugin so it's a bit of a catch 22. I'm going to talk to
>> the project stakeholders and see what they want to do. I'll let the list
>> know what comes out of that.
>>
>> Thanks again!
>>
>> - Justin
>>
>> On Nov 12, 2018 2:44 AM, "Andrea Aime" 
>> wrote:
>>
>> Hi Justin,
>> I believe your assessment is correct, also in terms of effort, it should
>> be easier to add time support to the imagemosaic-jdbc module.
>>
>> I'm however a bit worried about the module, the history shows very little
>> changes and most of them are
>> side effects of refactors happening elsewhere, which makes me wonder how
>> much "life" still remains in the module:
>>
>>
>> https://github.com/geotools/geotools/commits/master/modules/plugin/imagemosaic-jdbc/src/main
>>
>> Cheers
>> Andrea
>>
>>
>> On Tue, Nov 6, 2018 at 9:04 PM Justin Deoliveira 
>> wrote:
>>
>>> Hi folks,
>>>
>>> I have a need to publish a mosaic composed of tiles from a postgis
>>> raster table in a time series. From what I can tell for the two mosaic
>>> options the situation is:
>>>
>>> - the core imagemosaic reader can't read tiles from a postgis raster
>>> table
>>> - the imagemosaic-jdbc plugin can't do time
>>>
>>> If either of those assumptions are wrong please let me know, I'm basing
>>> that on what i've found in the docs and mailing lists, and a quick code
>>> review but could have easily missed something.
>>>
>>> Assuming those assumptions are both correct I am thinking going the
>>> route of adding support for a time dimension to the imagemosaic-jdbc plugin
>>> is probably the path of least resistance? Before I start down that path I
>>> thought I would reach out to the experts. Any thoughts much appreciated.
>>>
>>> Thanks!
>>>
>>> -Justin
>>>
>>>
>>>
>>>
>>> ___
>>> Geoserver-devel mailing list
>>> Geoserver-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>>
>>>
>>
>> --
>>
>> Regards, Andrea Aime == GeoServer Professional Services from the experts!
>> Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime
>> @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054
>> Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339
>> 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it
>> --- *Con riferimento
>> alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 -
>> Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni
>> circostanza inerente alla presente email (il suo contenuto, gli eventuali
>> allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i
>> destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per
>> errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
>> sarei comunque grato se potesse darmene notizia. This email is intended
>> only for the person or entity to which it is addressed and may contain
>> informati

Re: [Geoserver-devel] Mosaics with postgis raster and time

[Justin Deoliveira]

Thanks for the input Andrea. Yeah I'm a bit weary of putting time into the
image mosaic jdbc plugin if it's falling toward unsupported. But I don't
think the project scope will allow for going the route of trying to update
the core plugin so it's a bit of a catch 22. I'm going to talk to the
project stakeholders and see what they want to do. I'll let the list know
what comes out of that.

Thanks again!

- Justin

On Nov 12, 2018 2:44 AM, "Andrea Aime"  wrote:

Hi Justin,
I believe your assessment is correct, also in terms of effort, it should be
easier to add time support to the imagemosaic-jdbc module.

I'm however a bit worried about the module, the history shows very little
changes and most of them are
side effects of refactors happening elsewhere, which makes me wonder how
much "life" still remains in the module:

https://github.com/geotools/geotools/commits/master/modules/plugin/imagemosaic-jdbc/src/main

Cheers
Andrea


On Tue, Nov 6, 2018 at 9:04 PM Justin Deoliveira  wrote:

> Hi folks,
>
> I have a need to publish a mosaic composed of tiles from a postgis raster
> table in a time series. From what I can tell for the two mosaic options the
> situation is:
>
> - the core imagemosaic reader can't read tiles from a postgis raster table
> - the imagemosaic-jdbc plugin can't do time
>
> If either of those assumptions are wrong please let me know, I'm basing
> that on what i've found in the docs and mailing lists, and a quick code
> review but could have easily missed something.
>
> Assuming those assumptions are both correct I am thinking going the route
> of adding support for a time dimension to the imagemosaic-jdbc plugin is
> probably the path of least resistance? Before I start down that path I
> thought I would reach out to the experts. Any thoughts much appreciated.
>
> Thanks!
>
> -Justin
>
>
>
>
> ___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>

-- 

Regards, Andrea Aime == GeoServer Professional Services from the experts!
Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime
@geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054
Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339
8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it
--- *Con riferimento
alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 -
Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni
circostanza inerente alla presente email (il suo contenuto, gli eventuali
allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i
destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per
errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
sarei comunque grato se potesse darmene notizia. This email is intended
only for the person or entity to which it is addressed and may contain
information that is privileged, confidential or otherwise protected from
disclosure. We remind that - as provided by European Regulation 2016/679
“GDPR” - copying, dissemination or use of this e-mail or the information
herein by anyone other than the intended recipient is prohibited. If you
have received this email by mistake, please notify us immediately by
telephone or e-mail.*
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] Mosaics with postgis raster and time

[Justin Deoliveira]

Hi folks,

I have a need to publish a mosaic composed of tiles from a postgis raster
table in a time series. From what I can tell for the two mosaic options the
situation is:

- the core imagemosaic reader can't read tiles from a postgis raster table
- the imagemosaic-jdbc plugin can't do time

If either of those assumptions are wrong please let me know, I'm basing
that on what i've found in the docs and mailing lists, and a quick code
review but could have easily missed something.

Assuming those assumptions are both correct I am thinking going the route
of adding support for a time dimension to the imagemosaic-jdbc plugin is
probably the path of least resistance? Before I start down that path I
thought I would reach out to the experts. Any thoughts much appreciated.

Thanks!

-Justin
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] hazelcast/jdbcconfig cache: why?

[Justin Deoliveira]

I can't recall anything specific sorry. When I worked on that code it was
very much a prototype that I never put through any sort of stress or scale
testing. I suspect I used that because it "just worked" in the development
environment I was working in.

On Wed, Aug 8, 2018, 7:44 AM Niels Charlier  wrote:

> Justin,
>
> Related question, do you by any chance remember why you made a "reload
> synchroniser" and made it the default instead of "event synchroniser" which
> is much more efficient and generates far less traffic. Furthermore, I found
> that if you generate a whole lot of events after each other (causing
> reloads in all the other nodes)  there is a chance at some point you will
> get a deadlock in the cache and your node becomes malfunctioning. The issue
> is however very hard to replicate or to debug.
>
> Regards
>
> Niels
>
> On 04-07-18 15:16, Justin Deoliveira wrote:
>
> I haven't committed to that module in many years so I am the wrong person
> to ask. I would start by looking at someone who more recently has made
> changes to it, someone from Boundless perhaps. I will say when I worked on
> it it was a prototype, something that hadn't seen any use in production, so
> I am not surprised if it has issues like this. Not an uncommon occurrence
> for community modules I would say. Given no-one else has responded it seems
> safe for you to make whatever changes to it you see fit.
>
> On Wed, Jul 4, 2018 at 6:06 AM Andrea Aime 
> wrote:
>
>> On Wed, Jul 4, 2018 at 1:37 PM, Niels Charlier  wrote:
>>
>>> Nobody answers... does anyone know who developed this? Was it Justin?
>>>
>>
>> I believe he was... see first commit in both these files:
>>
>> https://github.com/geoserver/geoserver/commits/master/src/community/hz-cluster/src/main/java/org/geoserver/cluster/ClusterConfig.java
>>
>> https://github.com/geoserver/geoserver/commits/master/src/community/hz-cluster/pom.xml
>>
>>
>>> Do we still have a maintainer for the hzcluster module?
>>>
>>
>> No idea...
>>
>> Regards
>> Andrea
>> ==
>>
>> GeoServer Professional Services from the experts! Visit
>> http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf
>> Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa
>> (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549
>> http://www.geo-solutions.it http://twitter.com/geosolutions_it
>> --- *Con riferimento
>> alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 -
>> Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni
>> circostanza inerente alla presente email (il suo contenuto, gli eventuali
>> allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i
>> destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per
>> errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
>> sarei comunque grato se potesse darmene notizia. This email is intended
>> only for the person or entity to which it is addressed and may contain
>> information that is privileged, confidential or otherwise protected from
>> disclosure. We remind that - as provided by European Regulation 2016/679
>> “GDPR” - copying, dissemination or use of this e-mail or the information
>> herein by anyone other than the intended recipient is prohibited. If you
>> have received this email by mistake, please notify us immediately by
>> telephone or e-mail.*
>>
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> Geoserver-devel mailing list
>> Geoserver-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] [JIRA] (GEOS-8871) Request demos fail when a proxy base url is set

[Justin Deoliveira (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Justin Deoliveira created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoServer /  GEOS-8871  
 
 
  Request demos fail when a proxy base url is set
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Affects Versions: 
 2.13.2  
 
 
Assignee: 
 Justin Deoliveira  
 
 
Components: 
 Wicket UI  
 
 
Created: 
 01/Aug/18 10:07 PM  
 
 
Priority: 
  Low  
 
 
Reporter: 
 Justin Deoliveira  
 

  
 
 
 
 

 
 The configured proxy base url is being looked up but isn't actually utilized to check the incoming request, so it always fails. Fix is simple.   
 

  
 
 
  
 

 
 
 

 
 
 Add Comment

Re: [Geoserver-devel] hazelcast/jdbcconfig cache: why?

[Justin Deoliveira]

I haven't committed to that module in many years so I am the wrong person
to ask. I would start by looking at someone who more recently has made
changes to it, someone from Boundless perhaps. I will say when I worked on
it it was a prototype, something that hadn't seen any use in production, so
I am not surprised if it has issues like this. Not an uncommon occurrence
for community modules I would say. Given no-one else has responded it seems
safe for you to make whatever changes to it you see fit.

On Wed, Jul 4, 2018 at 6:06 AM Andrea Aime 
wrote:

> On Wed, Jul 4, 2018 at 1:37 PM, Niels Charlier  wrote:
>
>> Nobody answers... does anyone know who developed this? Was it Justin?
>>
>
> I believe he was... see first commit in both these files:
>
> https://github.com/geoserver/geoserver/commits/master/src/community/hz-cluster/src/main/java/org/geoserver/cluster/ClusterConfig.java
>
> https://github.com/geoserver/geoserver/commits/master/src/community/hz-cluster/pom.xml
>
>
>> Do we still have a maintainer for the hzcluster module?
>>
>
> No idea...
>
> Regards
> Andrea
>
> ==
>
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf
> Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa
> (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549
> http://www.geo-solutions.it http://twitter.com/geosolutions_it
> --- *Con riferimento
> alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 -
> Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni
> circostanza inerente alla presente email (il suo contenuto, gli eventuali
> allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i
> destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per
> errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
> sarei comunque grato se potesse darmene notizia. This email is intended
> only for the person or entity to which it is addressed and may contain
> information that is privileged, confidential or otherwise protected from
> disclosure. We remind that - as provided by European Regulation 2016/679
> “GDPR” - copying, dissemination or use of this e-mail or the information
> herein by anyone other than the intended recipient is prohibited. If you
> have received this email by mistake, please notify us immediately by
> telephone or e-mail.*
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] [Geotools-devel] [Geowebcache-devel] Codebase reformat using Google/AOSP format

[Justin Deoliveira]

+1


On April 15, 2018 at 7:55:46 AM, Andrea Aime (andrea.a...@geo-solutions.it)
wrote:

Hi Ian,
yep, I surely hope it will make everybody's life easier in the medium-long
term,
even if there will be an adjustment period at the beginning

Cheers
Andrea

On Sun, Apr 15, 2018 at 2:25 PM, Ian Turton  wrote:

> +1
>
> Thanks for this, it will make life so much easier
>
> Ian
>
> On 15 April 2018 at 10:47, Andrea Aime 
> wrote:
>
>> Hi all,
>> sorry for the cross posting, but this proposal is best applied on all
>> projects toghether, and would
>> have the same contents on all projects (if really needed, I can
>> copy/paste on GeoServer's wiki):
>>
>> https://github.com/geotools/geotools/wiki/Codebase-Reformat
>>
>> The last discussion and vote showed that everybody is comfortable with
>> the AOSP format, so that's
>> the one that has been chosen.
>>
>> Please vote :-)
>>
>> Once voting is done we'll have to coordinate a bit in order to avoid
>> major issues with pull request
>> merging (although I believe some work will end up having merge issues
>> anyways, don't think we
>> can review and merge all outstanding pull requests).
>>
>> Cheers
>> Andrea
>>
>> ==
>> GeoServer Professional Services from the experts! Visit
>> http://goo.gl/it488V for more information.
>> ==
>>
>> Ing. Andrea Aime
>> @geowolf
>> Technical Lead
>>
>> GeoSolutions S.A.S.
>> Via di Montramito 3/A
>> 
>> 55054  Massarosa
>> 
>> (LU)
>> 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.
>>
>>
>> 
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> Geowebcache-devel mailing list
>> geowebcache-de...@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geowebcache-devel
>>
>>
>
>
> --
> Ian Turton
>



--

Regards,

Andrea Aime

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

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
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

Re: [Geoserver-devel] Issues with new EntitéGénérique data folders

[Justin Deoliveira]

I know this issue well… I think I am actually be the cause of it :) And
yes, I have this issue consisently on osx and windows, linux seems to
handle it a bit more gracefully.

I think your (2) question hints at the best solution going forward (at
least that was the consensus the last time we discussed it iirc), and that
is not to use the name of the directory as the absolute source of the
feature type name, instead use what you find in the featuretype.xml config
file. This would allow us to encode the directory names in a more
universally file system friendly way, but still support feature types with
“extended characters” in them.

Perhaps that is easier now with the recent work done to abstract away raw
resource access, not sure.

$0.02

On November 28, 2017 at 11:15:24 AM, Torben Barsballe (
tbarsba...@boundlessgeo.com) wrote:

Hello All,

In the past week or so, I've been running into some issues with some of the
new files added under /data, namely the two versions of "
data/citensg-1.0/workspaces/sf/sf/EntitéGénérique"

As far as I can determine, there are two folders named the same thing,
differing only in the unicode encoding of the "é".

Some filesystems, including the macOS filesystem, don't like this (similar
to case-sensitive files).

Locally, these two folders are treated as the same folder, which means the
files in them are permanently marked as modified and staged, since their
contents differ between the two folders.

This makes using the geoserver repo rather difficult.

I have been able to workaround the issue by marking the files as locally
ignored, which works fine as long as I stay on master, but means that I
can't switch to older branches that don't have these files (I get a warning
that the changes will get overwritten). This makes backporting commits
quite difficult.
So far, I have not been able to find a workaround for changing branches -
to do so I have to undo my local ignores, temporarily commit the
problematic files, then checkout the old branch and do whatever I need to
do there, then later reset the temporary commit when I return to the master
branch.

So, I have a couple questions:

1. Is anyone else having similar issues (I assume it is affecting all macOS
developers, I wonder if it also affects Windows developers). If so, have
you figured out any alternate workarounds?

2. Is it absolutely necessary to have two folders with effectively the same
name in the same directory? At the very least, is it possible to have them
in different directories?

Torben
--

Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org!
http://sdm.link/slashdot___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Who force pushed to 2.12.x?

[Justin Deoliveira]

I am sure folks are aware but GitHub supports “protected branches” that
outright disable force pushes. Extremely useful feature :) Looking in
github it looks like it was used in the past: master, and branches 2.5.x -
2.8.x are protected but no others are. Probably a useful thing to add to
the process when creating a new maintenance branch would be to go into
GitHub and add that branch as a protected one. It looks like it is possible
to do it via the GitHub api as well, so also possible to add to the release
scripts as well.

$0.02

On October 27, 2017 at 7:18:38 PM, Ben Caradoc-Davies (b...@transient.nz)
wrote:

Merged.

On 28/10/17 13:55, Ben Caradoc-Davies wrote:
> I have submitted a pull request:
> https://github.com/geoserver/geoserver/pull/2613
>
> This pull request contains:
>
> - The six substantive commits on my local 2.12.x branch (listed earlier)
>
> - Cherry-picked from master (I *assume* this was a straightforward
> cherry-pick to backport to 2.12.x):
> 9dfdf50de9094d778302be467bf11c334485515f [GEOS-8353] Ensure KML
> validates without being online.
>
> I did *not* include:
>
> Commit 3f472c02b06a7d13851ee9e8523684ca7b752397 by Andrea Aime
> [GEOS-8360] xStream security warning
>
> because I think it has already been cherry-picked onto the new 2.12.x as
> https://github.com/geoserver/geoserver/pull/2613.
>
> This leaves only the changes listed in this Jenkins build:
> https://build.geoserver.org/view/geoserver/job/geoserver-2.12.x/37/changes
>
> Alessio, I do not know if you intended to remove these changes. Please
> re-apply them to 2.12.x if that was your intent.
>
> Kind regards,
>

-- 
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

--

Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Speeding up the GeoServer build by splitting some modules

[Justin Deoliveira]

I am obviously not in a place to approve / disapprove but I’ll add that
your breakdown makes a lot of sense to me.

On Fri, Oct 13, 2017 at 9:30 AM Andrea Aime 
wrote:

> Hi,
> as with the thread on geotools-devel, there seems to be a distinct lack of
> enthusiams
> for the topic.
> Can at least get a sense if there are people opposed to the changes I'm
> proposing?
> I'd like to know before starting to split modules apart :-)
>
> Cheers
> Andreda
>
>
> On Wed, Oct 11, 2017 at 6:36 PM, Andrea Aime  > wrote:
>
>> Hi,
>> following up the geotools-devel thread on speeding up the build, I've
>> made some checks on
>> GeoServer as well.
>>
>> 
>> Please let's not start a discussion about tests being integration and
>> thus slow, we all know that,
>> but I'm trying to discuss something that can be done with limited
>> resources here,
>> not planning the next 10 years of development or selling an idea for the
>> next code sprint :-)
>> (it's a fair conversation topic, if you want to start it please just do
>> so in a separate mail thread).
>> 
>>
>> Compared to GeoTools the build takes longer because, among other reasons,
>> it parallelizes a lot less.
>> The "chain of death" keeping the build in low parallel mode is, roughly:
>> main->wfs->wms->restconfig->app-schema-test
>>
>> The main module takes here 1:20, and everything else depends on it. A
>> large chunk of that time is
>> spent running security related tests.
>> I'm only semi serious here, but as far as I can see, it could be
>> beneficial to move the securty
>> tests to their own module (e.g., security/core) while leaving the
>> security classes in main.
>> I'm just semi-serious because I realize splitting apart the classes and
>> their tests is not that great,
>> but at the same time, it could easily shave off 30-60 seconds off the
>> critical path.
>>
>> The WMS dependency onto WFS is hard to un-tangle, I've tried already some
>> years ago and
>> eventually gave up, it would require its own mini-sprint imho... so off
>> the board for this discussion.
>>
>> Restconfig is where things get interesting and actually doable in a
>> relatively short time.
>> Restconfig is a slow module to build, and has to wait onto all core OGC
>> services to be built, but it
>> does not have to be that way: I propose we split the service support part
>> into a small per service
>> module, e.g.:
>>
>>- gs-restconfig-wfs
>>- gs-restconfig-wms
>>- gs-restconfig-wcs
>>- gs-restconfig-wps (missing today, no way to configure WPS from REST)
>>- gs-restconfig-csw (missing today, no way to configure CSW from REST)
>>
>> Basically gs-restconfig would contain the core abstract service
>> controller class, and the "one class modules"
>> would add the templates, extra code, and tests (side effect, we'd make
>> the service rest configuration
>> actually pluggable).
>> There are also 4-5 a few tests hitting the OGC services as part of the
>> tests, those could also be moved
>> to the service specific restconfig module.
>> This way the main gs-restconfig module could start building as soon as
>> gs-main has completed.
>>
>> The other module that should be split imho is the app-schema-test one, in
>> the current build, and
>> on my current machine, it runs alone for 55 seconds after any other
>> module has terminated building.
>> The reason being that it depends on too many things, wfs, wms,
>> restconfig.
>> I believe the module mostly does WFS tests with a few WMS and I believe
>> just one REST test, so can
>> we split it into three parts that can start running as soon as their
>> dependencies are made available?
>>
>>- app-schema-wfs-test
>>- app-schema-wms-test
>>- app-schema-rest-test
>>
>> Cheers
>> Andrea
>>
>> ==
>> GeoServer Professional Services from the experts! Visit
>> http://goo.gl/it488V for more information.
>> ==
>>
>> Ing. Andrea Aime
>> @geowolf
>> Technical Lead
>>
>> GeoSolutions S.A.S.
>> Via di Montramito 3/A
>> 55054  Massarosa (LU)
>> phone: +39 0584 962313 <+39%200584%20962313>
>> fax: +39 0584 1660272 <+39%200584%20166%200272>
>> mob: +39  339 8844549 <+39%20339%20884%204549>
>>
>> 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 

Re: [Geoserver-devel] build.geoserver.org cite breakout

[Justin Deoliveira]

Hey Torben, yeah, by all means let’s move them over if they are still in
use, feel free to fork them over. Let me know if I can do anything to help.

On Thu, Oct 12, 2017 at 12:13 PM Torben Barsballe <
tbarsba...@boundlessgeo.com> wrote:

> Thanks Justin, will do.
>
> Less importantly, it looks like geoserver-cite-tools is referencing a
> couple other submodules that only exist in your account:
>
>-
>
> https://github.com/jdeolive/cite1/tree/b5c3a1b8423ed4014d36203348efa92e077d18a1
>-
>
> https://github.com/jdeolive/cite-scripts/tree/9937bd36c2377f7692ab7856307f78a067de8112
>
> Those two still exist and work fine, but perhaps we should consider
> migrating them to the geoserver org?
>
> Torben
>
> On Thu, Oct 12, 2017 at 11:04 AM, Justin Deoliveira <jdeol...@gmail.com>
> wrote:
>
>> Hey Torben,
>>
>> Yeah, that repo was moved from my personal account into the geoserver
>> org. The version in geoserver has that commit:
>>
>>
>> https://github.com/geoserver/teamengine/commit/e4dda71c90ba601d39847d19969b4d617f90bb70
>>
>> So if you update where the submodule is pointing too you should be good.
>>
>> On Thu, Oct 12, 2017 at 11:10 AM Torben Barsballe <
>> tbarsba...@boundlessgeo.com> wrote:
>>
>>> We made a bunch of progress yesterday, but are still following up on
>>> some issues. The current problem:
>>>
>>> geoserver/geoserver-cite-tools has a submodule that is referencing a
>>> commit that doesn't exist:
>>> https://github.com/jdeolive/teamengine/tree/e4dda71c90ba601d39847d19969b4d617f90bb70
>>>
>>> This submodule was last updated in 2012:
>>> https://github.com/geoserver/geoserver-cite-tools/commit/b068a8aab6c4e81fb3c0ca723971b7ee89e3569a
>>>
>>> Justin - looks like you made that commit, and the submodule is
>>> referencing your fork. Any comment?
>>>
>>> Torben
>>> On Wed, Oct 11, 2017 at 4:48 PM, Jody Garnett <jody.garn...@gmail.com>
>>> wrote:
>>>
>>>> Thanks Justin, sorry about the time conflict - we may end up sending
>>>> you some questions.
>>>>
>>>> --
>>>> Jody Garnett
>>>>
>>>> On 11 October 2017 at 05:53, Justin Deoliveira <jdeol...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hey guys, sorry for not responding to the poll, totally missed it.
>>>>> Unfortunately the proposed time doesn’t work for me. That said I am not
>>>>> sure how useful I’ll be to the discussion anyways.
>>>>>
>>>>> On Tue, Oct 10, 2017 at 3:12 PM Jody Garnett <jody.garn...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Only the two of us responded to the doodle poll, see you tomorrow!
>>>>>>
>>>>>> --
>>>>>> Jody Garnett
>>>>>>
>>>>>> On 10 October 2017 at 11:55, Ben Caradoc-Davies <b...@transient.nz>
>>>>>> wrote:
>>>>>>
>>>>>>> I am available on (your) Wednesday at that time (the second option).
>>>>>>> Doodle poll?
>>>>>>>
>>>>>>> On 11/10/17 06:58, Jody Garnett wrote:
>>>>>>>
>>>>>>>> - Wednesday (tomorrow)
>>>>>>>>
>>>>>>>> https://www.timeanddate.com/worldclock/meetingdetails.html?year=2017=10=12=0=0=0=256=264=55=605
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Ben Caradoc-Davies <b...@transient.nz>
>>>>>>> Director
>>>>>>> Transient Software Limited <http://transient.nz/>
>>>>>>> New Zealand
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>> --
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>> ___
>>>> Geoserver-devel mailing list
>>>> Geoserver-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>>>
>>>>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] build.geoserver.org cite breakout

[Justin Deoliveira]

Hey Torben,

Yeah, that repo was moved from my personal account into the geoserver org.
The version in geoserver has that commit:


https://github.com/geoserver/teamengine/commit/e4dda71c90ba601d39847d19969b4d617f90bb70

So if you update where the submodule is pointing too you should be good.

On Thu, Oct 12, 2017 at 11:10 AM Torben Barsballe <
tbarsba...@boundlessgeo.com> wrote:

> We made a bunch of progress yesterday, but are still following up on some
> issues. The current problem:
>
> geoserver/geoserver-cite-tools has a submodule that is referencing a
> commit that doesn't exist:
> https://github.com/jdeolive/teamengine/tree/e4dda71c90ba601d39847d19969b4d617f90bb70
>
> This submodule was last updated in 2012:
> https://github.com/geoserver/geoserver-cite-tools/commit/b068a8aab6c4e81fb3c0ca723971b7ee89e3569a
>
> Justin - looks like you made that commit, and the submodule is referencing
> your fork. Any comment?
>
> Torben
> On Wed, Oct 11, 2017 at 4:48 PM, Jody Garnett <jody.garn...@gmail.com>
> wrote:
>
>> Thanks Justin, sorry about the time conflict - we may end up sending you
>> some questions.
>>
>> --
>> Jody Garnett
>>
>> On 11 October 2017 at 05:53, Justin Deoliveira <jdeol...@gmail.com>
>> wrote:
>>
>>> Hey guys, sorry for not responding to the poll, totally missed it.
>>> Unfortunately the proposed time doesn’t work for me. That said I am not
>>> sure how useful I’ll be to the discussion anyways.
>>>
>>> On Tue, Oct 10, 2017 at 3:12 PM Jody Garnett <jody.garn...@gmail.com>
>>> wrote:
>>>
>>>> Only the two of us responded to the doodle poll, see you tomorrow!
>>>>
>>>> --
>>>> Jody Garnett
>>>>
>>>> On 10 October 2017 at 11:55, Ben Caradoc-Davies <b...@transient.nz>
>>>> wrote:
>>>>
>>>>> I am available on (your) Wednesday at that time (the second option).
>>>>> Doodle poll?
>>>>>
>>>>> On 11/10/17 06:58, Jody Garnett wrote:
>>>>>
>>>>>> - Wednesday (tomorrow)
>>>>>>
>>>>>> https://www.timeanddate.com/worldclock/meetingdetails.html?year=2017=10=12=0=0=0=256=264=55=605
>>>>>>
>>>>>
>>>>> --
>>>>> Ben Caradoc-Davies <b...@transient.nz>
>>>>> Director
>>>>> Transient Software Limited <http://transient.nz/>
>>>>> New Zealand
>>>>>
>>>>
>>>>
>>
>>
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> Geoserver-devel mailing list
>> Geoserver-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>
>>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] build.geoserver.org cite breakout

[Justin Deoliveira]

Hey guys, sorry for not responding to the poll, totally missed it.
Unfortunately the proposed time doesn’t work for me. That said I am not
sure how useful I’ll be to the discussion anyways.

On Tue, Oct 10, 2017 at 3:12 PM Jody Garnett  wrote:

> Only the two of us responded to the doodle poll, see you tomorrow!
>
> --
> Jody Garnett
>
> On 10 October 2017 at 11:55, Ben Caradoc-Davies  wrote:
>
>> I am available on (your) Wednesday at that time (the second option).
>> Doodle poll?
>>
>> On 11/10/17 06:58, Jody Garnett wrote:
>>
>>> - Wednesday (tomorrow)
>>>
>>> https://www.timeanddate.com/worldclock/meetingdetails.html?year=2017=10=12=0=0=0=256=264=55=605
>>>
>>
>> --
>> Ben Caradoc-Davies 
>> Director
>> Transient Software Limited 
>> New Zealand
>>
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] build.geoserver.org cite breakout

[Justin Deoliveira]

It feels like a lifetime ago that I worked on any of that stuff but I am
happy to try and provide any help that I can. Do you guys have a time yet?

On Tue, Oct 3, 2017 at 5:59 PM Jody Garnett  wrote:

> Thanks Ben, I can help - during work hours or late evening (so plenty of
> overlap with you).
>
> Justin are you available at all? You have the most detailed knowledge on
> how these jobs were setup.
>
> --
> Jody Garnett
>
> On 3 October 2017 at 16:14, Ben Caradoc-Davies  wrote:
>
>> I can help. I just requested shell access on the server (but will need to
>> see if my dynamic IP address can be accommodated).
>>
>> Kind regards,
>> Ben.
>>
>>
>> On 04/10/17 09:49, Jody Garnett wrote:
>>
>>> Coming out of todays geoserver-devel meeting ... who is available to set
>>> up
>>> cite tests on the new server?
>>>
>>> The jobs have been migrated over, we need a bit of back and forth to
>>> ensure
>>> they start up correctly, have access to their expected database before
>>> shutting off ares.
>>> --
>>> Jody Garnett
>>>
>>>
>>>
>>>
>>> --
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>
>>>
>>>
>>> ___
>>> Geoserver-devel mailing list
>>> Geoserver-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>>
>>>
>> --
>> Ben Caradoc-Davies 
>> Director
>> Transient Software Limited 
>> New Zealand
>>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Backporting the KML centroid improvements

[Justin Deoliveira]

Thanks Jody! The work has backported to 2.11.

On Wed, Aug 2, 2017 at 5:24 PM Jody Garnett <jody.garn...@gmail.com> wrote:

> Sounds fine Justin; thanks for the contribution.
>
> --
> Jody Garnett
>
> On 1 August 2017 at 19:32, Justin Deoliveira <jdeol...@gmail.com> wrote:
>
>> Hi folks,
>>
>> I’m interested in backporting the work I did for GSIP 160, the KML
>> placemark placement stuff. Any objections? As a reminder all the options
>> are additive so it doesn’t change any of the default behaviour, so it
>> should be pretty innocuous.
>>
>> Thanks!
>>
>> -Justin
>>
>>
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> Geoserver-devel mailing list
>> Geoserver-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>
>>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] Backporting the KML centroid improvements

[Justin Deoliveira]

Hi folks,

I’m interested in backporting the work I did for GSIP 160, the KML
placemark placement stuff. Any objections? As a reminder all the options
are additive so it doesn’t change any of the default behaviour, so it
should be pretty innocuous.

Thanks!

-Justin
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Vote on Placemark proposal

[Justin Deoliveira]

Thanks to everyone who weighed in on this one, i’ve gone ahead and merged
the change and marked the proposal as complete.

One small change though, I found that making the new options to clip and
force containment the default behaviour introduced a number of failures in
the test cases, some of which are kind of subtle and have the chance of
tripping up users as well so I decided to play it safe for now and keep the
behaviour as is. So all the new kml centroid options are still opt-in.

On Mon, Jul 10, 2017 at 11:30 AM Kevin Smith <smit...@draconic.ca> wrote:

> If you don't think vector tiles label points are relevant that's good
> enough for me.  I just want to watch out for corners we might paint
> ourselves into.
>
> +1
>
>
> On 2017-07-05 07:45 PM, Justin Deoliveira wrote:
>
> I kind of disagree with trying to generalize the parameters now… if
> another format comes along and adds a similar capability will it really
> have the exact same options with the exact same semantics? I am kind of
> doubtful.
>
> Unless there is a strong consensus that this has to happen I’m inclined to
> leave the options as is and KML specific until there is a more concrete
> need to coalesce them.
>
> On Wed, Jul 5, 2017 at 1:29 PM Kevin Smith <smit...@draconic.ca> wrote:
>
>> On 2017-07-05 11:56 AM, Jody Garnett wrote:
>> > Hey Justin / Kevin:
>> >
>> > Was talking with Kevin last week, he is looking to fine tuning the
>> > output of point locations to use for labeling when doing vector tile
>> > output.
>> >
>> > So you are both working on "calculating a better centroid" - can you
>> > share top level format options to avoid duplication?
>> >
>> >
>> _options=centroid_contain:true;centroid_samples:10;centroid_clip:true
>> >
>> > +1 to your GSIP, I do want to hear from Kevin if we can :)
>>
>> Yes this makes sense, At the moment I'm just working on including
>> precomputed label points in the vector tiles using the existing labeler,
>> but it's quite likely that would benefit from this kind of additional
>> control in future, so it would make sense to do it in a format agnostic
>> way now (at least in terms of keywords we're adding).
>>
>>
>> --
>> Kevin Michael Smith
>> <smit...@draconic.ca>
>>
>>
>>
> --
> Kevin Michael Smith<smit...@draconic.ca> <smit...@draconic.ca>
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Vote on Placemark proposal

[Justin Deoliveira]

I kind of disagree with trying to generalize the parameters now… if another
format comes along and adds a similar capability will it really have the
exact same options with the exact same semantics? I am kind of doubtful.

Unless there is a strong consensus that this has to happen I’m inclined to
leave the options as is and KML specific until there is a more concrete
need to coalesce them.

On Wed, Jul 5, 2017 at 1:29 PM Kevin Smith  wrote:

> On 2017-07-05 11:56 AM, Jody Garnett wrote:
> > Hey Justin / Kevin:
> >
> > Was talking with Kevin last week, he is looking to fine tuning the
> > output of point locations to use for labeling when doing vector tile
> > output.
> >
> > So you are both working on "calculating a better centroid" - can you
> > share top level format options to avoid duplication?
> >
> >
> _options=centroid_contain:true;centroid_samples:10;centroid_clip:true
> >
> > +1 to your GSIP, I do want to hear from Kevin if we can :)
>
> Yes this makes sense, At the moment I'm just working on including
> precomputed label points in the vector tiles using the existing labeler,
> but it's quite likely that would benefit from this kind of additional
> control in future, so it would make sense to do it in a format agnostic
> way now (at least in terms of keywords we're adding).
>
>
> --
> Kevin Michael Smith
> 
>
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] Vote on Placemark proposal

[Justin Deoliveira]

Hi folks,

I was hoping to call this proposal to a vote:

  https://github.com/geoserver/geoserver/wiki/GSIP-160

It’s been updated with the latest feedback from Andrea and Jody and should
be ready to go.

Thanks!

-Justin
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Proposal for KML placemark placement enhancements

[Justin Deoliveira]

Thanks for the feedback everyone. I’ve updated the proposal as per all of
the feedback here, and submitted the pull request.

https://github.com/geoserver/geoserver/pull/2443

I’ll give all of that a bit of time to settle and then I’ll poke the list
for an official vote.

Thanks!

On Thu, Jun 29, 2017 at 8:16 AM Justin Deoliveira <jdeol...@gmail.com>
wrote:

> Thanks Jody, sounds like definitely consensus for the second option so
> I’ll update the proposal and code.
>
> Regarding making the format options more general… I imagine there is
> potential for this to apply to other formats but until we have something
> more concrete my gut tells me to keep this KML specific for now, and expand
> its scope when we have another format option that wants to do the same
> thing.
>
>
> On Wed, Jun 28, 2017 at 6:24 PM Jody Garnett <jody.garn...@gmail.com>
> wrote:
>
>> I like the top-level format option.
>>
>> Is there any other output format that has to handle centroid? If so we
>> could replace
>> "kmcentroid_contain:true;kmcentroid_samples:10;kmcentroid_clip:true" with
>> "centroid_contain:true;centroid_samples:10;centroid_clip:true" (and then
>> documenting the kml format as supporting these options).
>>
>> --
>> Jody Garnett
>>
>> On 28 June 2017 at 07:34, Justin Deoliveira <jdeol...@gmail.com> wrote:
>>
>>> Hi folks,
>>>
>>> I did an initial sanity check on this change a few months back, and am
>>> now ready to push forward so I whipped up a proposal.
>>>
>>> https://github.com/geoserver/geoserver/wiki/GSIP-160
>>>
>>> Feedback appreciated.
>>>
>>> Once there is a concensus on the proposal I’ll update the current branch
>>> with documentation updates for KML, and then submit the pull request.
>>>
>>> Thanks!
>>>
>>> -Justin
>>>
>>>
>>> --
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> ___
>>> Geoserver-devel mailing list
>>> Geoserver-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>>
>>>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] Proposal for KML placemark placement enhancements

[Justin Deoliveira]

Hi folks,

I did an initial sanity check on this change a few months back, and am now
ready to push forward so I whipped up a proposal.

https://github.com/geoserver/geoserver/wiki/GSIP-160

Feedback appreciated.

Once there is a concensus on the proposal I’ll update the current branch
with documentation updates for KML, and then submit the pull request.

Thanks!

-Justin
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Library for retrieving system level and hardware info

[Justin Deoliveira]

On another project I work on we use the sigar library, but as you mention
it’s gone dead so we’re switching to OSHI. I’ve done some initial
experimentation with it and find it works great without all of the fuss of
JNI that sigar brings along. It looks like you’re going that way regardless
but I definitely recommend it.

On Thu, Apr 27, 2017 at 7:15 AM Nuno Oliveira <
nuno.olive...@geo-solutions.it> wrote:

> Hi,
>
> I would like to use the oshi library [1] in the context of GeoServer to
> retrieve system-level (maybe hardware info), its license is EPL.
> Does anyone sees any problem ?
>
> Oshi has a nice API and allow us to retrieve information about the
> system and is hardware [2]. This library uses JNA and no extra DLL needs
> to be installed. Major operating systems (Windows, Linux, Mac OS X and
> Unix based systems) are supported.
>
> Of all the existing alternatives for doing this in Java oshi seems to be
> the better option, oshi GitHub page provides a good summary about those
> alternatives [3]. Sigar [4] seems to be dead (the main page doesn't
> responds anymore) and it requires a DLL to be installed. JHardware [5]
> only has a single contributor, is mor elimited than oshi and Mac OS X
> seems to not be supported. Java OperatingSystemMXBean [6] doesn't
> provide much information and will probably not play well with non oracle
> JVM, although OpenJDK seems to support it.
>
> Regards,
>
> Nuno Oliveira
>
> [1] https://github.com/oshi/oshi
> [2]
>
> https://github.com/oshi/oshi/blob/master/oshi-core/src/test/java/oshi/SystemInfoTest.java
> [3] https://github.com/oshi/oshi#how-is-this-different-from-
> [4] https://github.com/hyperic/sigar
> [5] https://github.com/profesorfalken/jHardware
> [6]
>
> http://docs.oracle.com/javase/8/docs/jre/api/management/extension/com/sun/management/OperatingSystemMXBean.html
>
> --
> ==
> GeoServer Professional Services from the experts!
> Visit http://goo.gl/it488V for more information.
> ==
> Nuno Miguel Carvalho Oliveira
> @nmcoliveira
> Software Engineer
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054  Massarosa (LU)
> Italy
>
> phone: +39 0584 962313 <+39%200584%20962313>
> fax:   +39 0584 1660272 <+39%200584%20166%200272>
> mob:   +39  333 8128928 <+39%20333%20812%208928>
>
> 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.
>
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Convention for nested kvp inside of format_options

[Justin Deoliveira]

On Thu, Apr 13, 2017 at 7:45 AM Andrea Aime <andrea.a...@geo-solutions.it>
wrote:

> On Thu, Apr 13, 2017 at 3:41 PM, Justin Deoliveira <jdeol...@gmail.com>
> wrote:
>
>> I am not really following here… so if I am going to add a new format
>> option (for whatever output format not necessarily kml) are you saying it’s
>> only safe to use a very limited character set for it’s value space? Like
>> only alphanumerics and no symbols?
>>
>
> From your initial proposal I thought the splitting of the inner values was
> done inside FormatOptionsKvpParser, for any options new and old, using a
> well known (but new) separator, like @.
> If you instead post-parse the top level option in the KML handling code
> then there is no problem
>

My apologies for being unclear, yes I was proposing the second option.

>
> Cheers
> Andrea
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054  Massarosa (LU)
> phone: +39 0584 962313 <+39%200584%20962313>
> fax: +39 0584 1660272 <+39%200584%20166%200272>
> mob: +39  339 8844549 <+39%20339%20884%204549>
>
> 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.
>
> ---
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Convention for nested kvp inside of format_options

[Justin Deoliveira]

On Thu, Apr 13, 2017 at 7:30 AM Andrea Aime <andrea.a...@geo-solutions.it>
wrote:

> On Thu, Apr 13, 2017 at 3:17 PM, Justin Deoliveira <jdeol...@gmail.com>
> wrote:
>
>> Hey Andrea,
>>
>> Thanks for the input. Adding multiple keys at the top level would
>> certainly be an option, I just figured that since there are already quite a
>> few kml format options keys that having it encapsulated into a single one
>> would be a little nicer, and more aesthetically pleasing.
>>
>> To be clear I wasn’t proposing any change to format options syntax or
>> parser, just to see if someone had done this sort of thing before. My
>> thinking was that as long I chose delimiters that aren’t currently used (ie
>> not one of “&”, “=“, “:”, or “;”) then it should be pretty uninvasive and
>> not introduce any compatibility issues.
>>
>
> I'm not so sure, the format options parser is used for more than just
> format options:
>
> wfs/src/main/java/applicationContext.xml: id="wfsFormatOptionsKvpParser"
> class="org.geoserver.ows.kvp.FormatOptionsKvpParser"/>
> wms/src/main/java/applicationContext.xml:id="wmsFormatOptionsKvpParser"
> class="org.geoserver.ows.kvp.FormatOptionsKvpParser"/>
> wms/src/main/java/applicationContext.xml:id="wmsEnviromentKvpParser"
> class="org.geoserver.ows.kvp.FormatOptionsKvpParser">
> wms/src/main/java/applicationContext.xml:id="wmsLegendOptionsKvpParser"
> class="org.geoserver.ows.kvp.FormatOptionsKvpParser">
>

I see, so this would mean adding my option at the top level (rather than
inside of format_options) and having it use the same format_options syntax.
That would work.

>
> While I agree you can guess by looking at the existing format options what
> chars are not used (at least in the official GeoServer code base), I would
> not try to make the
> same guess about env vars (anything goes in there, imho). If you really
> want to go there, I'd add a parameter to limit the nested options
> properties to just the
> real format options parsers (the wms and wfs ones).
>

I am not really following here… so if I am going to add a new format option
(for whatever output format not necessarily kml) are you saying it’s only
safe to use a very limited character set for it’s value space? Like only
alphanumerics and no symbols?


>
> Cheers
> Andrea
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054  Massarosa (LU)
> phone: +39 0584 962313 <+39%200584%20962313>
> fax: +39 0584 1660272 <+39%200584%20166%200272>
> mob: +39  339 8844549 <+39%20339%20884%204549>
>
> 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.
>
> ---
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Convention for nested kvp inside of format_options

[Justin Deoliveira]

Hey Andrea,

Thanks for the input. Adding multiple keys at the top level would certainly
be an option, I just figured that since there are already quite a few kml
format options keys that having it encapsulated into a single one would be
a little nicer, and more aesthetically pleasing.

To be clear I wasn’t proposing any change to format options syntax or
parser, just to see if someone had done this sort of thing before. My
thinking was that as long I chose delimiters that aren’t currently used (ie
not one of “&”, “=“, “:”, or “;”) then it should be pretty uninvasive and
not introduce any compatibility issues.

Having the ability to use a JSON object would definitely be nice. From what
I understand of the current parser that would break it, but it seems like
it should be doable without too many changes. Perhaps I’ll explore that
option.

Anyways I’ve got a few avenues to explore here so I’ll do that. I’ll see
what makes most sense in the end and we can revisit this when I submit the
pull request for the change. Actually I’ll probably spark up some
discussion before that just to make sure my approach jives ok with folks.
For context I am working on GEOS-8033
<https://osgeo-org.atlassian.net/browse/GEOS-8033>.

-Justin

On Thu, Apr 13, 2017 at 6:11 AM Andrea Aime <andrea.a...@geo-solutions.it>
wrote:

> Hi Justin,
> I cannot remember any case like that. Does it really have to be structured
> that way, like,
> wouldn'it it be possible to just add N keys instead of a structured one?
> Worries:
>
>- The new separator would introduce a potential backwards
>compatibility issue (if legit part of any value, it would have to be
>espaped)
>- The KVP protocol would become more complex, with the risk of moving
>towards WPS like complexity (Execute does not have a KVP binding anymore in
>WPS 2.0 because of that)
>
> If they keys are not predictable, thinking out loud, what about supporting
> a JSON encoded document as an alternative syntax, at that point?
>
> format_options={"foo"{"opt1"="val1","opt2"="val2"}}
>
>
> Cheers
> Andrea
>
>
>
> On Thu, Apr 13, 2017 at 1:46 PM, Justin Deoliveira <jdeol...@gmail.com>
> wrote:
>
>> Hi folks,
>>
>> I am wondering if there is a convention for encoding key value pairs
>> inside of a single format_options kvp? Basically I want to add a new kml
>> format option, but I want that option to have multiple options within it.
>> The structure would look something like this:
>>
>> format_options:
>>foo:
>>   opt1: val1
>>   opt2: val2
>>
>> I am wondering if there is any precedent for encoding this type of info
>> in a way that doesn’t break the format_options parser. If there is I’ll use
>> that, if not I was thinking maybe using @ and , ... something like:
>>
>> format_options=foo:opt1@val1,opt2@val2;
>>
>> Any thoughts? Suggestions welcome :)
>>
>> Thanks.
>>
>> -Justin
>>
>>
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> Geoserver-devel mailing list
>> Geoserver-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>
>>
>
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054  Massarosa (LU)
> phone: +39 0584 962313 <+39%200584%20962313>
> fax: +39 0584 1660272 <+39%200584%20166%200272>
> mob: +39  339 8844549 <+39%20339%20884%204549>
>
> 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.
>
>
>
&g

[Geoserver-devel] Convention for nested kvp inside of format_options

[Justin Deoliveira]

Hi folks,

I am wondering if there is a convention for encoding key value pairs inside
of a single format_options kvp? Basically I want to add a new kml format
option, but I want that option to have multiple options within it. The
structure would look something like this:

format_options:
   foo:
  opt1: val1
  opt2: val2

I am wondering if there is any precedent for encoding this type of info in
a way that doesn’t break the format_options parser. If there is I’ll use
that, if not I was thinking maybe using @ and , ... something like:

format_options=foo:opt1@val1,opt2@val2;

Any thoughts? Suggestions welcome :)

Thanks.

-Justin
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] REST API Refresh Discussion

[Justin Deoliveira]

Good stuff!

With regard to the advanced dispatcher stuff, indeed that is what is
throwing you off. I’ve worked around this (also in a spring webmvc project)
by doing the following in a servlet filter.

root="/api"
if (servletPath != null && servletPath.startsWith(root)) {
//hack to deal with the GeoServer "advanced dispatch", the point here
is that
// we want to expose our api directly at "/api"
req = new HttpServletRequestWrapper(r) {
@Override
public String getRequestURI() {
return super.getRequestURI().replace(root, root + root);
}
};
}

There may be a better/cleaner way to do this, but this worked.

Also, if I can offer a suggestion about the endpoint name, using something
like “/api” might be a bit more aesthetically pleasing than “/restng”… and
more inline with how I’ve seen other modern servers expose restful apis,
fwiw.

-Justin


On Wed, Mar 15, 2017 at 10:42 AM Devon Tucker 
wrote:

> Hi all!
>
> Even though I'm not coming to the REST refresh sprint I've been doing some
> preparatory/research for it. I'm wondering if anyone on the list has
> started looking at it yet or worked out an example? I took a stab
> yesterday, it definitely raised some questions.
>
> Here's what I did:
>
> - Created a new top level module, rest-ng, that uses Spring MVC
> - Created a StyleController in order to recreate our styles REST endpoint.
> - Mapped this endpoint to "/restng/styles"
> - Returned a list of StyleInfo objects
> - Attempted to configure a new HttpMessageConverter to potentially handle
> the FreeMarker HTML responses
>
> That's about it. Just this raised a decent few questions and problems for
> me:
>
> - Right off the bat despite mapping my new endpoint to "/restng/styles" I
> found that it actually ended up being mapped to "/rest/restng/styles". I
> can't for the life of me figure out why that's happening. I tried removing
> the existing rest and restconfig modules from the project, removed the REST
> wrapper config and still had this issue. Maybe not a big issue in practice,
> since we want all the end points to be under /rest presumably, but it'd
> certainly be nice to know WHY this happens. Something to do with the
> AdvancedDispatchFilter maybe? (In fact after a little digging this seems to
> be the "culprit")
>
> - Conflicting Spring MVC contexts. I used the 
> directive to enable Spring MVC in my module. Then I added a new
> HttpMessageConverter (like this https://dzone.com/articles/customizing)
> to customize response handling. I could see the new converter being
> instantiated and added to the list of converters, however during the
> response cycle it was nowhere to be found. It seemed like internally there
> was another Spring context that was being used that had the default
> converters. If I remove the  directive from my
> context then my new converter DOES get used though. This is interesting
> though because the only references to Spring MVC are in community.
>
> - How should HTML responses be handled? Spring MVC RestControllers aren't
> really meant to return HTML. AFAICT the options are use the actual
> ModelAndView functionality with freemarker views, which would involve
> separate controller methods for HTML calls, or to create a new
> HttpMessageConverter to handle HTML requests. Both probably have issues.
> Creating a new MessageConverter is a little problematic, since these are
> centralized and orthogonal to the actual controllers. HTML responses in the
> current REST framework rely a lot on the type hierarchy of the RESTlet
> controller that handles the request. It's a little tougher to do it this
> way in Spring MVC because the response encoding happens outside the
> controller lifecycle.
>
> - This seems a little more straightforward, but I assume we want to re-use
> all the existing XML/JSON serialization. This will require custom
> MessageConverters for those.
>
> I think that's it for now. Sorry for the wall of text.
>
> Cheers,
> Devon
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] [JIRA] (GEOS-8033) Handle placemark placement when centroid of geometry not contained within

[Justin Deoliveira (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Justin Deoliveira created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoServer /  GEOS-8033  
 
 
  Handle placemark placement when centroid of geometry not contained within   
 

  
 
 
 
 

 
Issue Type: 
  Improvement  
 
 
Affects Versions: 
 2.11-RC1  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 Google Earth KML Output  
 
 
Created: 
 15/Mar/17 2:49 PM  
 
 
Priority: 
  Medium  
 
 
Reporter: 
 Justin Deoliveira  
 

  
 
 
 
 

 
 At the moment placemark placement is based purely on the geometry centroid. Which, depending on the geometry may not fall inside of it. The image rendering code handles this by detecting this case and falling back to a sampling technique in order to find a better point that is contained within the polygon. The ask here would be to add this same capability to KML generation, either by default or perhaps by a format option.   
 

  
 
 
  
 

 
 
 

 
 
 Add Comment

Re: [Geoserver-devel] Jenkins CITE test script

[Justin Deoliveira]

I don’t think there was any particular reason why I didn’t add the script
to version control other than being lazy :) But Jody brings up a good point
to check for any passwords, etc…. I can’t recall if there is any of that in
there.

On Wed, Feb 22, 2017 at 2:23 PM Jody Garnett  wrote:

> I am happy to have this script saved into the build folder, and the cite
> jobs updated accordingly.
>
> I would double check that any credentials are passed into the script
> (rather than being hard coded). That is the only thing I can think of for
> why it would not be committed already.
>
> --
> Jody Garnett
>
> On 22 February 2017 at 13:28, Torben Barsballe <
> tbarsba...@boundlessgeo.com> wrote:
>
> The ares Jenkins server looks like it has a custom "run.sh" script in the
> "geoserver-cite" workspace used to run the CITE tests. As far as I can
> tell, this script is not tracked in version control anywhere.
>
> There is also a setEnv.sh file responsible for setting the java version
> (which is specific to the machine) and a forms directory containing a bunch
> of xml files representing OWS requests or HTML forms.
>
> The remaining directories all appear to be populated by the run.sh script,
> and include a copy of the current release artifacts, a copy of the current
> data directories used by the cite tests, a geoserver master checkout, and a
> cite master checkout.
>
> Unless someone can point me to a location where the "run.sh" script (and
> the contents of the "forms" dir) are saved, I think we should probably add
> this script to version control.
>
> Does anyone have any more information about this setup, or other thoughts?
>
> Torben
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] Community module for jdbc metrics

[Justin Deoliveira]

Hi folks,

I would like to add a new community module that utilizes some of the newly
added metrics stuff in geotools. The code adds a metrics callback that
captures timings/etc… on a request by request basis and an endpoint to get
at the info.

Future work on it (yet to be decided) being discussed is adding an
aggregated form of the metrics as well (probably by utilizing the
dropwizard metrics library).

Thanks!

-Justin
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Reminder: GeoTools / GeoServer Meeting at 19:30 UTC on Tuesday

[Justin Deoliveira]

Hey guys… I was hoping to attend today but I don’t see anyone on Skype… do
I have the time right?

On Tue, Feb 21, 2017 at 7:00 AM Rahkonen Jukka (MML) <
jukka.rahko...@maanmittauslaitos.fi> wrote:

> My apologies, I am unable to attend as well.
>
> -Jukka Rahkonen-
> 
> Ben Caradoc-Davies wrote:
> [Geoserver-devel] Reminder: GeoTools / GeoServer Meeting at 19:30 UTC on
> Tuesday
>
> GeoTools / GeoServer committee meeting on Skype at 19:30 UTC on Tuesday:
>
> http://www.timeanddate.com/worldclock/fixedtime.html?msg=GeoTools+%2F+GeoServer+Meeting=2017=2=21=19=30=0=1
>
> Please note my apologies: I will be unable to attend this meeting.
>
> --
> Ben Caradoc-Davies 
> Director
> Transient Software Limited 
> New Zealand
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Help needed getting Marlin in and enabled by default for GeoServer 2.11

[Justin Deoliveira]

Hey guys, I can help get it integrated into the mac installer if no one
else is tackling that part. I should have some cycles next week for that.

On Fri, Feb 17, 2017 at 1:21 AM Brad Hards  wrote:

> I've spent a little time on this (on and off over a pretty warm week -
> hard to
> code at 35C...).
>
> To test something different, I decided to check an openJDK build on Centos
> 7,
> using tomcat / war combination.
>
> It was a fair amount of "yak shaving", but I eventually got it built and
> running.
>
> However the renderer is still showing as Pisces. I do see the marlin jar
> (marline-0.7.3-Unsafe.jar) in the war file.  Haven't really started
> debugging
> yet, but wanted to offer up this data point if you have any suggestions, or
> just for consideration before merging it.
>
> Brad
>
>
>
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Make utility methods in OWS Dispatcher accesible

[Justin Deoliveira]

Changes make sense to me Torben, +1 fwiw.

On Tue, Feb 7, 2017 at 4:18 PM Torben Barsballe 
wrote:

> I am tinkering with a custom DispatcherCallback, and ran into a bunch of
> what are essentially utility methods in the OWS Dispatcher.
>
> I feel like these could be useful outside of Dispatcher (mainly for
> DispatcherCallback); does anyone have any objections to me making these
> methods public static?
>
> While this is technically an API change, it only adds functionality.
>
> PR with the methods I wish to change here:
> https://github.com/geoserver/geoserver/pull/2095
>
> All methods have no notable side effects.
>
>
> Torben
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Backport for node opts change (GEOS-7960)

[Justin Deoliveira]

Hey guys, didn’t hear any feedback on this so used by judgement and went
ahead and back ported to 2.10. The change is pretty small so will be easy
to back out if folks think it’s not appropriate.

On Fri, Feb 3, 2017 at 7:23 AM Justin Deoliveira <jdeol...@gmail.com> wrote:

> Hi folks,
>
> I recently merged the change for GEOS-7960
> <https://osgeo-org.atlassian.net/browse/GEOS-7960> to master and was
> wondering about a backport since it’s not a bug fix. There are also
> technically some api additions as well. Not sure what the policy is on back
> porting these types of things so thought I would ask. If it’s not
> appropriate that is fine, I can work with a local patch, albeit less ideal.
>
> Thanks!
>
> -Justin
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Improvements to REST API Documentation

[Justin Deoliveira]

I’ve used swagger (with the springfox library) on a springmvc project with
pretty good results. I am not sure it’s a replacement itself for the
end-user documentation we have, but they would definitely provide a very
useful tool for exploring the api. A few points.

- You are able to have it only scan particular packages for annotations, so
if you put all your controllers in a single package hierarchy I’ve found
the scanning time to be negligible
- In order to theme the documentation you need to fork the swagger-ui
project and do whatever theming and styling you deem fit if you’re not
happy with the default UI. What i’ve done on other projects is:
  1. fork the swagger-ui 
repository into our organization
  2. apply the styling and logo changes required
  3. add a pom file that packages up the resources as a jar that can easily
be depended on via maven
- The docs are kind of implicitly versioned because they are driven from
annotations in our code. That said the swagger model supports the notion of
a “version” if you version your api separately from the rest of the codebase

-Justin

On Fri, Feb 3, 2017 at 11:07 AM Andrea Aime 
wrote:

> HI Matt,
> I don't know the tool, but wondering:
>
>- Is it going to make the REST api documentation into a separate
>documentation set as the user docs?
>- Can we version it along with GeoServer like we do with the user docs?
>- Can it be customized to have the GeoServer colors and logos?
>- What about restlets that require longer docs, are these going to be
>embedded in the code?
>
> It's also the first time I see the wiki page. The "Annotation driven" part
> scares me quite a bit, can you make
> sure the annotation classpath scan is not going to make the startup time
> longer? We are constantly fighting to keep
> it at bay, we might have to make sure the packages containing
>
> Cheers
> Andrea
>
>
> On Fri, Feb 3, 2017 at 5:55 PM, Matt Kruszewski <
> mkruszew...@boundlessgeo.com> wrote:
>
> Hi Mike,
>
> Given the upcoming switch to Spring MVC for the REST API, I wanted to
> start a conversation about possible improvements for the REST documentation
> (GEOS-7931). One option is Swagger, which has a lot of supporting tooling
> and is able to automatically generate docs from Spring MVC annotations --
> though some additional annotations might be required to flesh things out.
> What experience does everyone have with REST documentation formats and
> tools?
>
> Jody and I are doing some initial research and prototyping, and we have
> gathered our notes so far on the wiki (
> https://github.com/geoserver/geoserver/wiki/REST-API-Refresh).
>
> Thanks,
> Matt Kruszewski
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>
>
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054  Massarosa (LU)
> phone: +39 0584 962313 <+39%200584%20962313>
> fax: +39 0584 1660272 <+39%200584%20166%200272>
> mob: +39  339 8844549 <+39%20339%20884%204549>
>
> 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 

[Geoserver-devel] Backport for node opts change (GEOS-7960)

[Justin Deoliveira]

Hi folks,

I recently merged the change for GEOS-7960
 to master and was
wondering about a backport since it’s not a bug fix. There are also
technically some api additions as well. Not sure what the policy is on back
porting these types of things so thought I would ask. If it’s not
appropriate that is fine, I can work with a local patch, albeit less ideal.

Thanks!

-Justin
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] GeoServerNodeInfo outside of wicket UI

[Justin Deoliveira]

You asked for it :P

  https://github.com/geoserver/geoserver/pull/2079


On Mon, Jan 30, 2017 at 9:40 AM Jody Garnett <jody.garn...@gmail.com> wrote:

> Excellent - bring it on :)
>
> --
> Jody Garnett
>
> On 30 January 2017 at 08:23, Justin Deoliveira <jdeol...@gmail.com> wrote:
>
> Hi folks,
>
> I have a need where I would like to get access to data provided via
> GEOSERVER_NODE_OPTS but in a module that doesn’t depend on the UI
> modules. Currently it looks like all the infrastructure for parsing and
> representing the parameter lives in the web modules. While I could just add
> a dependency on web-core I was thinking it potentially made sense to move
> some of that stuff info main.
>
> What I am thinking is this:
>
>- Introduce an interface named something like GeoServerNodeData that
>would be the “data object” for the properties stored in the node opts
>parameter. It would also come with a default implementation that does all
>the non-UI bits of what DefaultGeoServerNodeInfo does now.
>-
>
>Update GeoServerNodeInfo adding an accessor to get at the “node data”.
>Something like:
>
>  interface GeoServerNodeInfo {
>  GeoServerNodeData getData();
>  }
>
>-
>
>Update GeoServerNodeInfo.getId() to call through to getData(), and/or
>perhaps deprecate it?
>
>  interface GeoServerNodeInfo {
>  default String getId() {
> return getData().getId();
>  }
>  }
>
>
> Does that make sense? If folks are ok with the idea I'll whip up a patch.
> I am happy to do a proposal as well but I think the changes for this one
> should be pretty minimal and non-distruptive.
>
> Thanks!
>
> -Justin
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] [JIRA] (GEOS-7960) Factor out non-ui specific data from GeoServerNodeInfo.

[Justin Deoliveira (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Justin Deoliveira created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoServer /  GEOS-7960  
 
 
  Factor out non-ui specific data from GeoServerNodeInfo.   
 

  
 
 
 
 

 
Issue Type: 
  Improvement  
 
 
Assignee: 
 Justin Deoliveira  
 
 
Created: 
 31/Jan/17 5:39 PM  
 
 
Priority: 
  Medium  
 
 
Reporter: 
 Justin Deoliveira  
 

  
 
 
 
 

 
 The motivation is to be able to use the class outside of the wicket ui context.  
 

  
 
 
  
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v1000.718.4#100026-sha1:69a2752

Re: [Geoserver-devel] GeoServerNodeInfo outside of wicket UI

[Justin Deoliveira]

Hey Jody,

Correct, I just need it at the java level, no apis required at this time.

-Justin

On Mon, Jan 30, 2017 at 9:27 AM Jody Garnett <jody.garn...@gmail.com> wrote:

> That sounds fine, you just need this at the java level right, no rest api
> access for node info.
>
> --
> Jody Garnett
>
> On 30 January 2017 at 08:23, Justin Deoliveira <jdeol...@gmail.com> wrote:
>
> Hi folks,
>
> I have a need where I would like to get access to data provided via
> GEOSERVER_NODE_OPTS but in a module that doesn’t depend on the UI
> modules. Currently it looks like all the infrastructure for parsing and
> representing the parameter lives in the web modules. While I could just add
> a dependency on web-core I was thinking it potentially made sense to move
> some of that stuff info main.
>
> What I am thinking is this:
>
>- Introduce an interface named something like GeoServerNodeData that
>would be the “data object” for the properties stored in the node opts
>parameter. It would also come with a default implementation that does all
>the non-UI bits of what DefaultGeoServerNodeInfo does now.
>-
>
>Update GeoServerNodeInfo adding an accessor to get at the “node data”.
>Something like:
>
>  interface GeoServerNodeInfo {
>  GeoServerNodeData getData();
>  }
>
>-
>
>Update GeoServerNodeInfo.getId() to call through to getData(), and/or
>perhaps deprecate it?
>
>  interface GeoServerNodeInfo {
>  default String getId() {
> return getData().getId();
>  }
>  }
>
>
> Does that make sense? If folks are ok with the idea I'll whip up a patch.
> I am happy to do a proposal as well but I think the changes for this one
> should be pretty minimal and non-distruptive.
>
> Thanks!
>
> -Justin
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] GeoServerNodeInfo outside of wicket UI

[Justin Deoliveira]

Hi folks,

I have a need where I would like to get access to data provided via
GEOSERVER_NODE_OPTS but in a module that doesn’t depend on the UI modules.
Currently it looks like all the infrastructure for parsing and representing
the parameter lives in the web modules. While I could just add a dependency
on web-core I was thinking it potentially made sense to move some of that
stuff info main.

What I am thinking is this:

   - Introduce an interface named something like GeoServerNodeData that
   would be the “data object” for the properties stored in the node opts
   parameter. It would also come with a default implementation that does all
   the non-UI bits of what DefaultGeoServerNodeInfo does now.
   -

   Update GeoServerNodeInfo adding an accessor to get at the “node data”.
   Something like:

 interface GeoServerNodeInfo {
 GeoServerNodeData getData();
 }

   -

   Update GeoServerNodeInfo.getId() to call through to getData(), and/or
   perhaps deprecate it?

 interface GeoServerNodeInfo {
 default String getId() {
return getData().getId();
 }
 }


Does that make sense? If folks are ok with the idea I'll whip up a patch. I
am happy to do a proposal as well but I think the changes for this one
should be pretty minimal and non-distruptive.

Thanks!

-Justin
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] [JIRA] (GEOS-7933) Allow HttpErrorCodeException to carry a value for Content-Type header

[Justin Deoliveira (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Justin Deoliveira created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoServer /  GEOS-7933  
 
 
  Allow HttpErrorCodeException to carry a value for Content-Type header   
 

  
 
 
 
 

 
Issue Type: 
  Improvement  
 
 
Assignee: 
 Justin Deoliveira  
 
 
Created: 
 17/Jan/17 10:27 PM  
 
 
Priority: 
  Medium  
 
 
Reporter: 
 Justin Deoliveira  
 

  
 
 
 
 

 
 We allow the exception to set the status code and a payload, so it would make sense for it to report the content-type of the payload.  
 

  
 
 
  
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v1000.695.1#100025-sha1:c4480eb

Re: [Geoserver-devel] Backport of GEOS-7921

[Justin Deoliveira]

Awesome, thanks Andrea!

On Thu, Jan 12, 2017 at 2:57 AM Andrea Aime <andrea.a...@geo-solutions.it>
wrote:

> Hi Justin,
> looks simple enough, no objection to a backport from me :-)
>
> Cheers
> Andrea
>
> On Thu, Jan 12, 2017 at 1:44 AM, Justin Deoliveira <jdeol...@gmail.com>
> wrote:
>
> Hey folks,
>
> I recently made a small tweak to the dispatcher to not send back an error
> for HttpCodeException that has a status that isn’t an http error code. I
> was hoping to backport the change but since it’s not really a bug fix
> thought I would ask first. Here is the ticket and pull request for context:
>
>   https://osgeo-org.atlassian.net/browse/GEOS-7921
>   https://github.com/geoserver/geoserver/pull/2044
>
> Thanks!
>
> -Justin
>
>
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> ___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>
>
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054  Massarosa (LU)
> phone: +39 0584 962313 <+39%200584%20962313>
> fax: +39 0584 1660272 <+39%200584%20166%200272>
> mob: +39  339 8844549 <+39%20339%20884%204549>
>
> 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.
>
> ---
>
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] Backport of GEOS-7921

[Justin Deoliveira]

Hey folks,

I recently made a small tweak to the dispatcher to not send back an error
for HttpCodeException that has a status that isn’t an http error code. I
was hoping to backport the change but since it’s not really a bug fix
thought I would ask first. Here is the ticket and pull request for context:

  https://osgeo-org.atlassian.net/browse/GEOS-7921
  https://github.com/geoserver/geoserver/pull/2044

Thanks!

-Justin
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Dispatcher Simulation Mode

[Justin Deoliveira]

Hey folks,

Given the feedback I think it this live in a community module for now and
we’ll see how it evolves from there. Any objections? If not consider this
my request for a new community module. Thanks.

-Justin

On Thu, Dec 22, 2016 at 11:29 AM Justin Deoliveira <jdeol...@gmail.com>
wrote:

> On Thu, Dec 22, 2016 at 9:27 AM Andrea Aime <andrea.a...@geo-solutions.it>
> wrote:
>
> On Thu, Dec 22, 2016 at 2:23 PM, Justin Deoliveira <jdeol...@gmail.com>
> wrote:
>
> Thanks for the feedback Andrea. Comments inline.
>
> Now you are getting me a bit worried... maybe it's nothing, but the
> request objects were not designed to be returned back to the users,
> depending on how deep you go dumping them, you might end up revealing
> information that the admin does not want to be seen, such as for example
> the security filters being applied by something like GeoFence, or the
> datastore connection parameters (ok, that would be quite the deep scan in
> the object tree, but in the end all the info is actually linked and
> reachable from a GetMapRequest object for example).
>
> In other words, is it something that one would want to always have and
> would come with sane restriction to avoid leaking information, something
> allowed only to admins, something that it's core vs a plugin?
>
> Good point. What if we made it an explicit “opt-in” enabled only via
> configuration or a system property, etc…
>
> Another option could be to simply redact sensitive information when the
> user isn’t the admin… Or do you think there are too many cases of sensitive
> properties to handle?
>
>
> Hard to tell.. like, would it be ok to stop at any found catalog related
> information and just return its name instead of its details, which could
> reveal
> security restrictions (e.g., SecuredFeatureTypeInfo) ?
>
>
> In my immediate case yes, and I would say in general yes. The point of the
> call is not to provide a full dump of the request properties, more just to
> provide a representation of what the request will do. I think that for
> catalog objects, geotools objects… just displaying a name or id is enough
> to do that without providing anything deeper, which as you pointed out can
> definitely contain sensitive information.
>
>
>
>
>
> Fwiw I wasn’t planning on traversing the object deep enough to get down to
> anything like data store connection information. Just
>
>
> I was thinking you'd have allowed a user requestable expansion level like
> in the importer REST API.
> In general, depending on the protocol involved and the request structure
> (which might change over time) you might need
> to modify how deep you go. I believe at one time we expanded the expansion
> level in the logger to get more useful WPS information
> for example
>
>
> Yeah, I was thinking the same, allow “depth” to be specified in the
> request with a conservative default value.
>
> Thanks for all the feedback. I think at this point I have enough to start
> working on the code. I’ll report back when I have something more concrete
> working and we can continue discussion with a patch to look at. However if
> there are any more concerns I am happy to keep discussing now.
>
> Happy holidays!
>
> -Justin
>
>
> Cheers
> Andrea
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054  Massarosa (LU)
> phone: +39 0584 962313 <+39%200584%20962313>
> fax: +39 0584 1660272 <+39%200584%20166%200272>
> mob: +39  339 8844549 <+39%20339%20884%204549>
>
> 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
> proprieta

Re: [Geoserver-devel] Dispatcher Simulation Mode

[Justin Deoliveira]

On Thu, Dec 22, 2016 at 9:27 AM Andrea Aime <andrea.a...@geo-solutions.it>
wrote:

> On Thu, Dec 22, 2016 at 2:23 PM, Justin Deoliveira <jdeol...@gmail.com>
> wrote:
>
> Thanks for the feedback Andrea. Comments inline.
>
> Now you are getting me a bit worried... maybe it's nothing, but the
> request objects were not designed to be returned back to the users,
> depending on how deep you go dumping them, you might end up revealing
> information that the admin does not want to be seen, such as for example
> the security filters being applied by something like GeoFence, or the
> datastore connection parameters (ok, that would be quite the deep scan in
> the object tree, but in the end all the info is actually linked and
> reachable from a GetMapRequest object for example).
>
> In other words, is it something that one would want to always have and
> would come with sane restriction to avoid leaking information, something
> allowed only to admins, something that it's core vs a plugin?
>
> Good point. What if we made it an explicit “opt-in” enabled only via
> configuration or a system property, etc…
>
> Another option could be to simply redact sensitive information when the
> user isn’t the admin… Or do you think there are too many cases of sensitive
> properties to handle?
>
>
> Hard to tell.. like, would it be ok to stop at any found catalog related
> information and just return its name instead of its details, which could
> reveal
> security restrictions (e.g., SecuredFeatureTypeInfo) ?
>

In my immediate case yes, and I would say in general yes. The point of the
call is not to provide a full dump of the request properties, more just to
provide a representation of what the request will do. I think that for
catalog objects, geotools objects… just displaying a name or id is enough
to do that without providing anything deeper, which as you pointed out can
definitely contain sensitive information.



>
>
> Fwiw I wasn’t planning on traversing the object deep enough to get down to
> anything like data store connection information. Just
>
>
> I was thinking you'd have allowed a user requestable expansion level like
> in the importer REST API.
> In general, depending on the protocol involved and the request structure
> (which might change over time) you might need
> to modify how deep you go. I believe at one time we expanded the expansion
> level in the logger to get more useful WPS information
> for example
>

Yeah, I was thinking the same, allow “depth” to be specified in the request
with a conservative default value.

Thanks for all the feedback. I think at this point I have enough to start
working on the code. I’ll report back when I have something more concrete
working and we can continue discussion with a patch to look at. However if
there are any more concerns I am happy to keep discussing now.

Happy holidays!

-Justin

>
> Cheers
> Andrea
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054  Massarosa (LU)
> phone: +39 0584 962313 <+39%200584%20962313>
> fax: +39 0584 1660272 <+39%200584%20166%200272>
> mob: +39  339 8844549 <+39%20339%20884%204549>
>
> 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 co

Re: [Geoserver-devel] Dispatcher Simulation Mode

[Justin Deoliveira]

Thanks for the feedback Andrea. Comments inline.

On Thu, Dec 22, 2016 at 5:20 AM Andrea Aime <andrea.a...@geo-solutions.it>
wrote:

> On Tue, Dec 20, 2016 at 9:21 PM, Justin Deoliveira <jdeol...@gmail.com>
> wrote:
>
> Hi folks,
>
> I'm working on a project with a requirement as follows. Basically I want
> to be able to make a normal OGC (WMS, WFS, etc...) request to GeoServer,
> but I don't want it to fully execute. What I want is it to do pretty much
> all of the request parsing, but then return right before it goes to execute
> that request.
>
> The use case for this project is that the information from the parsed
> request is used to do some on-demand database setup and security that needs
> to happen before the request is executed.
>
> The security in terms of layer access you mean? Restrictions such as
> filters or property reduction won't be applied until actual data access for
> example.
>
The use case is more about general “provisioning” of the database that
needs to happen before hand.

>
>
> However, I can see this perhaps being a useful debugging feature as well.
> Just like other tools have a "dry run" or a "simulate" mode to allow you to
> try out something before actually doing it. Along that vein it could be
> useful to be able to do the same for a GeoServer request, to see how it
> will be processed and parsed, etc... before actually executing it, perhaps
> because it is a request that may take a long time, etc...
>
> Yep, why not.
>
>
> The change I am proposing is as follows. First add a special key value
> pair that will be recognized by the dispatcher (like simulate=true or
> something along those lines).
>
> Will it be recognized also for POST requests?
>

Yup. IIRC the dispatcher supports POST requests with a body but still
allows you to send params via query string as well.

Besides that, thinking out loud here, how about implementing it as a
> DispatcherCallback instead? Or the extra complication in the dispatcher is
> indeed minimal?
>

Yup, my thinking was that I can probably keep all of this code constrained
to a DispatcherCallback… although I was envisioning a bit of refactoring of
some of the utility code. If there are any dispatcher changes my guess is
they will be quite minimal.

>
>
> When the flag is set the dispatcher will do all of the request parsing and
> dispatch it normally does, except for when it gets to the point where it
> would execute the operation it would simply return with a response that
> includes a representation of the request it just parsed.
>
> For the representation of the response I was thinking output similar to
> the output of what the RequestObjectLogger produces, only encoded as
> something structured like JSON and/or XML.
>
>
> Now you are getting me a bit worried... maybe it's nothing, but the
> request objects were not designed to be returned back to the users,
> depending on how deep you go dumping them, you might end up revealing
> information that the admin does not want to be seen, such as for example
> the security filters being applied by something like GeoFence, or the
> datastore connection parameters (ok, that would be quite the deep scan in
> the object tree, but in the end all the info is actually linked and
> reachable from a GetMapRequest object for example).
> In other words, is it something that one would want to always have and
> would come with sane restriction to avoid leaking information, something
> allowed only to admins, something that it's core vs a plugin?
>
>
Good point. What if we made it an explicit “opt-in” enabled only via
configuration or a system property, etc…

Another option could be to simply redact sensitive information when the
user isn’t the admin… Or do you think there are too many cases of sensitive
properties to handle?

Fwiw I wasn’t planning on traversing the object deep enough to get down to
anything like data store connection information. Just

> I was also thinking that for such a request we might try to utilize an
> appropriate http response code. The *202 Accepted* looks like it could
> apply:
>
> *The request has been accepted for processing, but the processing has not
> been completed*
>
>
> Works for me
>
>
> And that's it. Let me know what y'all think. If folks feel this one is
> worth of a GSIP I am happy to whip one up.
>
> I would be happy either way
>
> Cheers
> Andrea
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054  Massarosa (LU)
> phone: +39 0584 962313 <+39%200584%20962313>
>

[Geoserver-devel] Dispatcher Simulation Mode

[Justin Deoliveira]

Hi folks,

I'm working on a project with a requirement as follows. Basically I want to
be able to make a normal OGC (WMS, WFS, etc...) request to GeoServer, but I
don't want it to fully execute. What I want is it to do pretty much all of
the request parsing, but then return right before it goes to execute that
request.

The use case for this project is that the information from the parsed
request is used to do some on-demand database setup and security that needs
to happen before the request is executed.

However, I can see this perhaps being a useful debugging feature as well.
Just like other tools have a "dry run" or a "simulate" mode to allow you to
try out something before actually doing it. Along that vein it could be
useful to be able to do the same for a GeoServer request, to see how it
will be processed and parsed, etc... before actually executing it, perhaps
because it is a request that may take a long time, etc...

The change I am proposing is as follows. First add a special key value pair
that will be recognized by the dispatcher (like simulate=true or something
along those lines). When the flag is set the dispatcher will do all of the
request parsing and dispatch it normally does, except for when it gets to
the point where it would execute the operation it would simply return with
a response that includes a representation of the request it just parsed.

For the representation of the response I was thinking output similar to the
output of what the RequestObjectLogger produces, only encoded as something
structured like JSON and/or XML.

I was also thinking that for such a request we might try to utilize an
appropriate http response code. The *202 Accepted* looks like it could
apply:

*The request has been accepted for processing, but the processing has not
been completed*

And that's it. Let me know what y'all think. If folks feel this one is
worth of a GSIP I am happy to whip one up.

Thanks!

-Justin
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/intel___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Funny requests sending the dispatcher belly up

[Justin Deoliveira]

I kind of agree with Even in that this request is bogus and really does
seem like it should be fixed on the sender side. That said the patch
doesn’t seem too invasive so looks like a sensible solution to me as well.
The worry is that if the dispatcher starts to try to accommodate these
kinds of client bugs and peculiarities how far down that rabbit hole will
one go :)

$0.02

On Fri, Dec 2, 2016 at 10:24 AM Andrea Aime 
wrote:

> On Fri, Dec 2, 2016 at 6:19 PM, Even Rouault 
> wrote:
>
> On vendredi 2 décembre 2016 17:52:37 CET Andrea Aime wrote:
>
> > Hi,
>
> > recently I've been wrestling with QGIS sending really funny requests to
>
> > GeoServer, that are causing
>
> > a not so nice ClassCastException. Here is a sample, it's a POST request
> at
>
> > this URL:
>
>
>
> FYI, I've been emailed about the same issue but from the perspective of
> QGIS. Ultimately, this should be fixed in QGIS since such requests are
> wrong and I wouldn't expect a WFS server to make sense of them.
>
>
> Interesting... wondering how you're going to implement that? Like, wiping
> out everything past the ? won't work with mapserver, that
> normally needs a reference to a mapfile.
> But maybe just removing service/request/version would do the trick.
>
> Do you already know in which version of QGIS the fix will land?
>
> Cheers
> Andrea
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054  Massarosa (LU)
> phone: +39 0584 962313 <+39%200584%20962313>
> fax: +39 0584 1660272 <+39%200584%20166%200272>
> mob: +39  339 8844549 <+39%20339%20884%204549>
>
> 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.
>
> ---
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] CatalogException behavior

[Justin Deoliveira]

Hey Torben

Someone can correct me if I'm wrong and we never quite formalized this but
here is my take/understanding. If the catalog throws an exception
deliberately then it should be responsible for leaving/restoring
modifications accordingly to the same state as before that method was
called. If that doesn't happen I would say it's a bug.

The catalog isn't however responsible for restoring any state "across
methods". For instance if adding a resource, then a layer and the layer
method throws an exception. Removing the resource would be the
responsibility of the client.

$0.02

-Justin

On Thu, Nov 17, 2016 at 12:29 PM Torben Barsballe <
tbarsba...@boundlessgeo.com> wrote:

> I was looking into GEOS-4754, and discovered that the documentation around
> "CatalogException" is rather unclear.
>
> Justin - you seem to be the original author of this code, so if you have
> any insight it would be helpful.
>
> My main question is: Is the Catalog responsible for reverting any changes
> it may have made when a CatalogException is thrown, or is this a
> responsibility of the client?
>
> More details here: https://osgeo-org.atlassian.net/browse/GEOS-7865
>
> Thanks
>
--
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Permission for new community module: OAuth2 Authtentication

[Justin Deoliveira]

Great to hear! I know a few users who will be excited to see this work! If
I could give a +1 you would have it :)

On Tue, Aug 30, 2016 at 6:47 AM Simone Giannecchini <
simone.giannecch...@geo-solutions.it> wrote:

> Dear All,
> on behalf of alessio, I am asking for the permission to create a new
> community module for GeoServer to allow it to authenticate users
> against an OAuth2 provider.
> The module will contain an implementation for using google accounts
> and will be used also for GeoNode in the near future.
>
> All I need is love (in the form of a +1).
>
> Regards,
> Simone Giannecchini
> ==
> GeoServer Professional Services from the experts!
> Visit http://goo.gl/it488V for more information.
> ==
> Ing. Simone Giannecchini
> @simogeo
> Founder/Director
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054  Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob:   +39  333 8128928
>
> 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.
>
>
> --
> ___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
--
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Backporting coverage/feature class stats to 2.8.x

[Justin Deoliveira]

Great, thanks guys.

On Thu, Jul 28, 2016 at 6:08 AM Andrea Aime <andrea.a...@geo-solutions.it>
wrote:

> No objection here :-)
>
> Cheers
> Andrea
>
> On Wed, Jul 27, 2016 at 5:20 PM, Justin Deoliveira <jdeol...@gmail.com>
> wrote:
>
>> Hi folks,
>>
>> I was wondering if anyone had any issue with me backporting the wps
>> classification work that was done a few months back to the 2.8.x branch?
>>
>> Thanks.
>>
>> -Justin
>>
>>
>> --
>> What NetFlow Analyzer can do for you? Monitors network bandwidth and
>> traffic
>> patterns at an interface-level. Reveals which users, apps, and protocols
>> are
>> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
>> J-Flow, sFlow and other flows. Make informed decisions using capacity
>> planning
>> reports.http://sdm.link/zohodev2dev
>> ___
>> Geoserver-devel mailing list
>> Geoserver-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>
>>
>
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054  Massarosa (LU)
> 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.
>
> ---
>
--
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] Backporting coverage/feature class stats to 2.8.x

[Justin Deoliveira]

Hi folks,

I was wondering if anyone had any issue with me backporting the wps
classification work that was done a few months back to the 2.8.x branch?

Thanks.

-Justin
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] [JIRA] (GEOS-7659) Class stats PPIO encoding fails with some XML drivers

[Justin Deoliveira (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Justin Deoliveira created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoServer /  GEOS-7659  
 
 
  Class stats PPIO encoding fails with some XML drivers   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Justin Deoliveira  
 
 
Components: 
 WPS  
 
 
Created: 
 27/Jul/16 3:07 AM  
 
 
Priority: 
  Medium  
 
 
Reporter: 
 Justin Deoliveira  
 

  
 
 
 
 

 
 Issue is that null is passed in for namespace and prefix when encoding content. Some xml drivers choke on this, safer is to pass in the empty string.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v1000.184.1#18-sha1:1fb1cc9

Re: [Geoserver-devel] [Geowebcache-devel] Using spring annotations to configure REST controllers

[Justin Deoliveira]

Yeah, enabling package scanning for a large package (like org.geoserver)
you would see a noticeable hit as spring starts up.

What I find works best is to enable package scanning and use of annotations
on a module by module basis where you turn it on only for specific
packages.

$0.02

On Sun, Jul 3, 2016 at 2:21 PM Andrea Aime 
wrote:

> On Sun, Jul 3, 2016 at 6:20 PM, Nuno Oliveira <
> nuno.olive...@geo-solutions.it> wrote:
>
>> What is community opinion about using spring annotations ?
>>
>
> No objection here, as long as they don't visibly affect build times (some
> of this magic might require
> Spring to do classpath scans).
>
> Cheers
> Andrea
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054  Massarosa (LU)
> 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.
>
> ---
>
> --
> Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] session fixation protection for geoserver

[Justin Deoliveira]

All the spring configuration related to security actually lives in this
file:
https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/applicationSecurityContext.xml

The way GeoServer configures spring security is pretty different from what
you’ll find in the spring security docs, especially since they use the
newer style where you work with higher level elements rather than raw bean
definitions.

You may be able to mix the two, or if you can figure out what those
elements boil down to into terms of bean definitions you can use that.


On Wed, Jun 22, 2016 at 12:31 AM Jody Garnett 
wrote:

> Each module in geoserver as an application-context.xml config file, they
> are all read in and used to configure the resulting applicaiton (this is
> why GeoServer can have "dropin" extensions that wire in new functionality).
>
> Here is an example from the gs-main.jar:
>
>
> https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/applicationContext.xml
>
> --
> Jody Garnett
>
> On 21 June 2016 at 11:51, Jason Newmoyer 
> wrote:
>
>> I would like to configure GeoServer to use Sping's session fixation
>> protection as described here:
>> http://docs.spring.io/spring-security/site/docs/3.0.x/reference/ns-config.html
>>
>> Basically, this copies the user session into a new one, with a new id,
>> when logging in.
>>
>> After some searching I can't seem to find the pertinent application
>> config file.
>>
>> Can anyone point me in the right direction?
>>
>> Jason Newmoyer
>> Newmoyer Geospatial Solutions
>> 843.606.0424
>> ja...@newmoyergeospatial.com
>>
>>
>>
>>
>> --
>> Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>> present their vision of the future. This family event has something for
>> everyone, including kids. Get more information and register today.
>> http://sdm.link/attshape
>> ___
>> Geoserver-devel mailing list
>> Geoserver-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>
>>
>
> --
> Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Possible bug in virtual services implementation

[Justin Deoliveira]

I believe this would have been me and no, I don’t think there was an
explicit need for this case, at least none that I can remember. It was just
a decision to be lenient in this case. The rationale being that since you
specified the workspace/namespace container in the url any namespace prefix
on the layer is meaningless. Which was a generally the design philosophy of
the virtual services work I did so you may find more stuff like that.

On Wed, Jun 15, 2016 at 2:06 AM Andrea Aime 
wrote:

> Hi,
> today I was chatting with Nuno and he referred to some code that blindly
> removes layer prefixes in virtual services,
> making a request like this one, actually work:
>
>
> http://demo.geo-solutions.it/geoserver/tiger/wms?service=WMS=1.1.0=GetMap=topp:giant_polygon==-180.0,-90.0,180.0,90.0=768=384=EPSG:4326=application/openlayers
>
> See? I'm asking for the tiger virtual service, and requesting a
> topp:giant_polygon layer in it. Considerations:
>
>- If I'm asking for a layer in another workspace, I should be denied
>access no?
>- The topp:giant_polygon layer does not exist to start with...
>(tiger:giant_polygon does, that's why it's working)
>
> Looks like a bug to me... anyone has a valid use case to keep this
> functionality as is?
>
> Cheers
> Andrea
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054  Massarosa (LU)
> 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.
>
> ---
>
> --
> What NetFlow Analyzer can do for you? Monitors network bandwidth and
> traffic
> patterns at an interface-level. Reveals which users, apps, and protocols
> are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning
> reports.
> http://pubads.g.doubleclick.net/gampad/clk?id=1444514421=/41014381
> ___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421=/41014381___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Same copyright header policy as GeoTools?

[Justin Deoliveira]

I think that’s a great idea! ;) … fwiw.

On Tue, Jun 14, 2016 at 9:34 AM Andrea Aime 
wrote:

> Hi,
> wondering, for the sake of consistency and simplicity, how about we adopt
> here the same copyright header policy as GeoTools?
>
> I guess this requires a proposal... with some copy pasting from
>
> https://github.com/geotools/geotools/wiki/Updates-to-Copyright-Header-Policy
>
> Right?
>
> Cheers
> Andrea
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054  Massarosa (LU)
> 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.
>
> ---
>
> --
> What NetFlow Analyzer can do for you? Monitors network bandwidth and
> traffic
> patterns at an interface-level. Reveals which users, apps, and protocols
> are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
> ___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] About scripting in geoserver

[Justin Deoliveira]

Hi Jorge,

The docs you are looking at are for the old “python” extension that
pre-dates the “script” extension. You should follow the documentation
located here:

  http://docs.geoserver.org/stable/en/user/community/scripting/index.html

In particular if you are looking to hook into wps you can find some details
and samples here:


http://docs.geoserver.org/stable/en/user/community/scripting/hooks.html#web-processing-service

Hope that helps.

-Justin

On Thu, Jun 2, 2016 at 5:36 AM Jorge Infante  wrote:

> Hi.
> I'm using geoserver 2.8.1, builded from sources, and on runtime format.
>
> I'm trying to run python code to do customs, in geoserver.
>
> I did install the wps extension, create the data_dir/scripts/wps
> directory, and put my sample.py on it.
> I'm not getting type py:sample on the demo/wps request builder.
> I did detect (in the builded from sources version), a message "2016-06-01
> 18:14:22,784 DEBUG [script.wps] - Skipping sample.py, no hook found"
>
> I did try, too, to install the python extension (documented on
> http://docs.geoserver.org/2.6.x/en/user/community/python/installation.html
> ).
> This method is no longer available in versions 2.8.x or higher? It was
> replaced by something else?
>
> Surely I'm wrong in the process. someone can give me a hint?
>
> TIA
>
> jorge infante
> rosario - santa fe - argentina
>
>
> --
> What NetFlow Analyzer can do for you? Monitors network bandwidth and
> traffic
> patterns at an interface-level. Reveals which users, apps, and protocols
> are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
> ___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Earn Money From Home!

[Justin Deoliveira]

Yeah, originally this bug fix was supposed to be funded through another
vehicle which is why I had a beat on it. But then it was decided to try out
through this “pay for pull” program. I was happy to play guinea pig.

On Thu, May 19, 2016 at 4:04 PM Ben Caradoc-Davies  wrote:

> Great! Looks like Justin already has a fix.
>
> Thanks Paul for publicising this. Anything that lowers that barrier for
> funded development has to be good for the long term.
>
> Kind regards,
> Ben.
>
> On 20/05/16 04:48, Paul Ramsey wrote:
> > Ha ha, but really:
> >
> > https://github.com/bcgov/databc-web-map-services/issues/1
> >
> > Part of the BC gov't "micro-purchasing" agreement, one of the issues
> > they'll pay to fix is a GeoServer issue. An ever better offer than
> > "I'll buy you a beer" -- $1000 in cold hard cash.
> >
> > P.
> >
> >
> --
> > Mobile security can be enabling, not merely restricting. Employees who
> > bring their own devices (BYOD) to work are irked by the imposition of MDM
> > restrictions. Mobile Device Manager Plus allows you to control only the
> > apps on BYO-devices by containerizing them, leaving personal data
> untouched!
> > https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
> > ___
> > Geoserver-devel mailing list
> > Geoserver-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/geoserver-devel
> >
>
> --
> Ben Caradoc-Davies 
> Director
> Transient Software Limited 
> New Zealand
>
--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Tabs to spaces discussion

[Justin Deoliveira]

As a committer, a former PSC member, and someone who hates tabs as much as
anyone, I would give this the most negative vote I could :) While I do hate
having to deal with tabs in source files it’s a small burden compared to
the mess that results from trying to merge into a file where formatting has
changed.

I would say open pull requests is probably not a great indication of how
much code there is out there branched off of GeoServer. If I look in my
local repository i have a lot of unmerged branches. There are probably a
lot of tickets with patch files on them, etc…

I’m all for enforcing spaces on new files added to the code base but I
think trying to go back and re-format existing files is opening up a can of
worms that probably isn’t worth it.

$0.02



On Fri, May 13, 2016 at 4:44 PM Torben Barsballe <
tbarsba...@boundlessgeo.com> wrote:

> Moving the discussion for https://github.com/geoserver/geoserver/pull/1598
> to the mailing lists.
>
> This is a non-functional change that has the potential to cause merge
> conflicts in some percentage of the currently open pull requests.
>
> This change has been discussed in the past, but has generally been
> considered too much of a hassle.
>
> A change of this magnitude will likely always be a hassle to deal with, so
> we might as well do it eventually. Given that we recently branched of
> 2.9.x, we are in a relatively good position to do this now. Unfortunately,
> there are also a lot (23) of Pull Requests open against GeoServer right
> now, which makes this a less attractive change at this point.
>
> Torben
>
> --
> Mobile security can be enabling, not merely restricting. Employees who
> bring their own devices (BYOD) to work are irked by the imposition of MDM
> restrictions. Mobile Device Manager Plus allows you to control only the
> apps on BYO-devices by containerizing them, leaving personal data
> untouched!
> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
> ___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] 2.9 beta2 Mac build

[Justin Deoliveira]

Change pushed.

On Wed, Apr 20, 2016 at 2:55 PM Jody Garnett <jody.garn...@gmail.com> wrote:

> Agreed, revert and we can add to the docs. The joys of testing - still it
> is why we do a beta.
>
> --
> Jody Garnett
>
> On 20 April 2016 at 13:53, Justin Deoliveira <jdeol...@gmail.com> wrote:
>
>> We did that before and it looks to be what is throwing off the mac
>> installer in GEOS-7508. When I update Info.plist and edit out that line
>> things come up fine. I guess that is what we get for trying to be smart :)
>>
>> Setting this property seems to prevent loading of the jre/security
>> directory, which then doesn’t pick up the configuration needed for the
>> basic encryption functions to function. The error message about the strong
>> encryption is misleading in this case… it’s the jasypt library trying to be
>> smart about providing an error message.
>>
>> So… given that we added this config to handle the case where users have
>> jai jars in global extension directories I vote we just revert that and
>> make osx folks aware of it with documentation.
>>
>> Thoughts?
>>
>> On Wed, Apr 20, 2016 at 9:36 AM Jody Garnett <jody.garn...@gmail.com>
>> wrote:
>>
>>> Is there any command line option we can provide to ignore these annoying
>>> system paths?
>>>
>>> Answer: "Set -Djava.ext.dirs=something harmless your startup"
>>>
>>>
>>>
>>> --
>>> Jody Garnett
>>>
>>> On 20 April 2016 at 08:23, Justin Deoliveira <jdeol...@gmail.com> wrote:
>>>
>>>> Ahhh… there were some jai jars lingering on my system. In my case they
>>>> were in /System/Library/Java/Extensions… Confirm that the bin package
>>>> starts up fine now.
>>>>
>>>> On Wed, Apr 20, 2016 at 9:14 AM Jody Garnett <jody.garn...@gmail.com>
>>>> wrote:
>>>>
>>>>> As per email yesterday (thanks Torben for the reminder) - remove JAI
>>>>> from  ~/Library/Java/Extensions allowed bin release to start up on
>>>>> mac.
>>>>>
>>>>> --
>>>>> Jody Garnett
>>>>>
>>>>> On 20 April 2016 at 07:14, Justin Deoliveira <jdeol...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hey folks,
>>>>>>
>>>>>> To look at GEOS-7508 I decided to do a local build. Before moving to
>>>>>> testing the dmg to replicate the issue Jody found I thought I would 
>>>>>> ensure
>>>>>> the bin package works on osx… since the dmg is essentially built from it,
>>>>>> and i’seeing issues around jai.
>>>>>>
>>>>>> Running the package straight away leads to:
>>>>>>
>>>>>> java.lang.NoClassDefFoundError: Could not initialize class
>>>>>> javax.media.jai.JAI
>>>>>>
>>>>>> at
>>>>>> org.geoserver.GeoserverInitStartupListener.contextInitialized(GeoserverInitStartupListener.java:88)
>>>>>>
>>>>>> at
>>>>>> org.eclipse.jetty.server.handler.ContextHandler.callContextInitialized(ContextHandler.java:800)
>>>>>>
>>>>>>
>>>>>> I tried moving the jars into the jetty lib folder, and also just
>>>>>> removing them outright and that gets further, but results in this error:
>>>>>>
>>>>>> java.lang.NoClassDefFoundError:
>>>>>> com/sun/media/imageioimpl/common/BogusColorSpace
>>>>>>
>>>>>> at
>>>>>> org.geoserver.config.impl.JAIEXTInfoImpl.(JAIEXTInfoImpl.java:34)
>>>>>>
>>>>>> at org.geoserver.config.impl.JAIInfoImpl.(JAIInfoImpl.java:56)
>>>>>>
>>>>>> at
>>>>>> org.geoserver.config.impl.GeoServerInfoImpl.(GeoServerInfoImpl.java:26)
>>>>>>
>>>>>> at
>>>>>> org.geoserver.config.impl.GeoServerFactoryImpl.createGlobal(GeoServerFactoryImpl.java:41)
>>>>>>
>>>>>> Looking around for BogusColorSpace I do notice the class being
>>>>>> references is slightly different than the one available from rt.jar on my
>>>>>> jvm:
>>>>>>
>>>>>>   com.sun.imageio.plugins.common.BogosColorSpace
>>>>>>
>>>>>> I also saw that uDig may have run up against this 

Re: [Geoserver-devel] 2.9 beta2 Mac build

[Justin Deoliveira]

We did that before and it looks to be what is throwing off the mac
installer in GEOS-7508. When I update Info.plist and edit out that line
things come up fine. I guess that is what we get for trying to be smart :)

Setting this property seems to prevent loading of the jre/security
directory, which then doesn’t pick up the configuration needed for the
basic encryption functions to function. The error message about the strong
encryption is misleading in this case… it’s the jasypt library trying to be
smart about providing an error message.

So… given that we added this config to handle the case where users have jai
jars in global extension directories I vote we just revert that and make
osx folks aware of it with documentation.

Thoughts?

On Wed, Apr 20, 2016 at 9:36 AM Jody Garnett <jody.garn...@gmail.com> wrote:

> Is there any command line option we can provide to ignore these annoying
> system paths?
>
> Answer: "Set -Djava.ext.dirs=something harmless your startup"
>
>
>
> --
> Jody Garnett
>
> On 20 April 2016 at 08:23, Justin Deoliveira <jdeol...@gmail.com> wrote:
>
>> Ahhh… there were some jai jars lingering on my system. In my case they
>> were in /System/Library/Java/Extensions… Confirm that the bin package
>> starts up fine now.
>>
>> On Wed, Apr 20, 2016 at 9:14 AM Jody Garnett <jody.garn...@gmail.com>
>> wrote:
>>
>>> As per email yesterday (thanks Torben for the reminder) - remove JAI
>>> from  ~/Library/Java/Extensions allowed bin release to start up on mac.
>>>
>>> --
>>> Jody Garnett
>>>
>>> On 20 April 2016 at 07:14, Justin Deoliveira <jdeol...@gmail.com> wrote:
>>>
>>>> Hey folks,
>>>>
>>>> To look at GEOS-7508 I decided to do a local build. Before moving to
>>>> testing the dmg to replicate the issue Jody found I thought I would ensure
>>>> the bin package works on osx… since the dmg is essentially built from it,
>>>> and i’seeing issues around jai.
>>>>
>>>> Running the package straight away leads to:
>>>>
>>>> java.lang.NoClassDefFoundError: Could not initialize class
>>>> javax.media.jai.JAI
>>>>
>>>> at
>>>> org.geoserver.GeoserverInitStartupListener.contextInitialized(GeoserverInitStartupListener.java:88)
>>>>
>>>> at
>>>> org.eclipse.jetty.server.handler.ContextHandler.callContextInitialized(ContextHandler.java:800)
>>>>
>>>>
>>>> I tried moving the jars into the jetty lib folder, and also just
>>>> removing them outright and that gets further, but results in this error:
>>>>
>>>> java.lang.NoClassDefFoundError:
>>>> com/sun/media/imageioimpl/common/BogusColorSpace
>>>>
>>>> at
>>>> org.geoserver.config.impl.JAIEXTInfoImpl.(JAIEXTInfoImpl.java:34)
>>>>
>>>> at org.geoserver.config.impl.JAIInfoImpl.(JAIInfoImpl.java:56)
>>>>
>>>> at
>>>> org.geoserver.config.impl.GeoServerInfoImpl.(GeoServerInfoImpl.java:26)
>>>>
>>>> at
>>>> org.geoserver.config.impl.GeoServerFactoryImpl.createGlobal(GeoServerFactoryImpl.java:41)
>>>>
>>>> Looking around for BogusColorSpace I do notice the class being
>>>> references is slightly different than the one available from rt.jar on my
>>>> jvm:
>>>>
>>>>   com.sun.imageio.plugins.common.BogosColorSpace
>>>>
>>>> I also saw that uDig may have run up against this recently, as I came
>>>> across this bug report:
>>>> https://osgeo-org.atlassian.net/browse/UDIG-2030
>>>>
>>>>   -Justin
>>>>
>>>>
>>>> --
>>>> Find and fix application performance issues faster with Applications
>>>> Manager
>>>> Applications Manager provides deep performance insights into multiple
>>>> tiers of
>>>> your business applications. It resolves application problems quickly and
>>>> reduces your MTTR. Get your free trial!
>>>> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
>>>> ___
>>>> Geoserver-devel mailing list
>>>> Geoserver-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>>>
>>>>
>>>
>
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] 2.9 beta2 Mac build

[Justin Deoliveira]

Ahhh… there were some jai jars lingering on my system. In my case they were
in /System/Library/Java/Extensions… Confirm that the bin package starts up
fine now.

On Wed, Apr 20, 2016 at 9:14 AM Jody Garnett <jody.garn...@gmail.com> wrote:

> As per email yesterday (thanks Torben for the reminder) - remove JAI from  
> ~/Library/Java/Extensions
> allowed bin release to start up on mac.
>
> --
> Jody Garnett
>
> On 20 April 2016 at 07:14, Justin Deoliveira <jdeol...@gmail.com> wrote:
>
>> Hey folks,
>>
>> To look at GEOS-7508 I decided to do a local build. Before moving to
>> testing the dmg to replicate the issue Jody found I thought I would ensure
>> the bin package works on osx… since the dmg is essentially built from it,
>> and i’seeing issues around jai.
>>
>> Running the package straight away leads to:
>>
>> java.lang.NoClassDefFoundError: Could not initialize class
>> javax.media.jai.JAI
>>
>> at
>> org.geoserver.GeoserverInitStartupListener.contextInitialized(GeoserverInitStartupListener.java:88)
>>
>> at
>> org.eclipse.jetty.server.handler.ContextHandler.callContextInitialized(ContextHandler.java:800)
>>
>>
>> I tried moving the jars into the jetty lib folder, and also just removing
>> them outright and that gets further, but results in this error:
>>
>> java.lang.NoClassDefFoundError:
>> com/sun/media/imageioimpl/common/BogusColorSpace
>>
>> at
>> org.geoserver.config.impl.JAIEXTInfoImpl.(JAIEXTInfoImpl.java:34)
>>
>> at org.geoserver.config.impl.JAIInfoImpl.(JAIInfoImpl.java:56)
>>
>> at
>> org.geoserver.config.impl.GeoServerInfoImpl.(GeoServerInfoImpl.java:26)
>>
>> at
>> org.geoserver.config.impl.GeoServerFactoryImpl.createGlobal(GeoServerFactoryImpl.java:41)
>>
>> Looking around for BogusColorSpace I do notice the class being references
>> is slightly different than the one available from rt.jar on my jvm:
>>
>>   com.sun.imageio.plugins.common.BogosColorSpace
>>
>> I also saw that uDig may have run up against this recently, as I came
>> across this bug report: https://osgeo-org.atlassian.net/browse/UDIG-2030
>>
>>   -Justin
>>
>>
>> --
>> Find and fix application performance issues faster with Applications
>> Manager
>> Applications Manager provides deep performance insights into multiple
>> tiers of
>> your business applications. It resolves application problems quickly and
>> reduces your MTTR. Get your free trial!
>> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
>> ___
>> Geoserver-devel mailing list
>> Geoserver-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>
>>
>
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] 2.9 beta2 Mac build

[Justin Deoliveira]

Hey folks,

To look at GEOS-7508 I decided to do a local build. Before moving to
testing the dmg to replicate the issue Jody found I thought I would ensure
the bin package works on osx… since the dmg is essentially built from it,
and i’seeing issues around jai.

Running the package straight away leads to:

java.lang.NoClassDefFoundError: Could not initialize class
javax.media.jai.JAI

at
org.geoserver.GeoserverInitStartupListener.contextInitialized(GeoserverInitStartupListener.java:88)

at
org.eclipse.jetty.server.handler.ContextHandler.callContextInitialized(ContextHandler.java:800)


I tried moving the jars into the jetty lib folder, and also just removing
them outright and that gets further, but results in this error:

java.lang.NoClassDefFoundError:
com/sun/media/imageioimpl/common/BogusColorSpace

at org.geoserver.config.impl.JAIEXTInfoImpl.(JAIEXTInfoImpl.java:34)

at org.geoserver.config.impl.JAIInfoImpl.(JAIInfoImpl.java:56)

at
org.geoserver.config.impl.GeoServerInfoImpl.(GeoServerInfoImpl.java:26)

at
org.geoserver.config.impl.GeoServerFactoryImpl.createGlobal(GeoServerFactoryImpl.java:41)

Looking around for BogusColorSpace I do notice the class being references
is slightly different than the one available from rt.jar on my jvm:

  com.sun.imageio.plugins.common.BogosColorSpace

I also saw that uDig may have run up against this recently, as I came
across this bug report: https://osgeo-org.atlassian.net/browse/UDIG-2030

  -Justin
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] geoserver 2.9-beta2 preflight testing

[Justin Deoliveira]

Thanks for the testing Jody. I’ll take a look at the mac dmg issue
tomorrow. Appears to be something around the unlimited strength encryption
jurisdiction files… but not sure. Might be somethign related to the server
it was built on. I’ll start by building locally and see if I can reproduce.

On Tue, Apr 19, 2016 at 5:52 PM Jody Garnett  wrote:

> Testing windows service install - does not start.
>
> (!) Error Service Control Manager "The GeoServer 2.9-beta2 service
> terminated with service-specific error Incorrect function.."
>
> Could not find logs, taking a wild guess and changing permissions on the
> data directory did not fix anything.
>
> Found the wrapper logs:
>
> STATUS | wrapper  | 2016/04/20 09:30:18 | GeoServer 2.9-beta2 installed.
> STATUS | wrapper  | 2016/04/20 09:30:18 | Starting the GeoServer 2.9-beta2
> service...
> STATUS | wrapper  | 2016/04/20 09:30:18 | --> Wrapper Started as Service
> STATUS | wrapper  | 2016/04/20 09:30:18 | Java Service Wrapper Community
> Edition 3.3.3
> STATUS | wrapper  | 2016/04/20 09:30:18 |   Copyright (C) 1999-2009 Tanuki
> Software, Ltd.  All Rights Reserved.
> STATUS | wrapper  | 2016/04/20 09:30:18 |
> http://wrapper.tanukisoftware.org
> STATUS | wrapper  | 2016/04/20 09:30:18 |
> STATUS | wrapper  | 2016/04/20 09:30:18 | Launching a JVM...
> INFO   | wrapper  | 2016/04/20 09:30:23 | Waiting to start...
> INFO   | jvm 1| 2016/04/20 09:30:24 | WrapperManager: Initializing...
> INFO   | jvm 1| 2016/04/20 09:30:25 | WrapperSimpleApp: Unable to
> locate the class org.mortbay.start.Main: java.lang.ClassNotFoundException:
> org.mortbay.start.Main
> INFO   | jvm 1| 2016/04/20 09:30:25 |
> INFO   | jvm 1| 2016/04/20 09:30:25 | WrapperSimpleApp Usage:
> INFO   | jvm 1| 2016/04/20 09:30:25 |   java
> org.tanukisoftware.wrapper.WrapperSimpleApp {app_class} [app_arguments]
> INFO   | jvm 1| 2016/04/20 09:30:25 |
> INFO   | jvm 1| 2016/04/20 09:30:25 | Where:
> INFO   | jvm 1| 2016/04/20 09:30:25 |   app_class:  The fully
> qualified class name of the application to run.
> INFO   | jvm 1| 2016/04/20 09:30:25 |   app_arguments:  The arguments
> that would normally be passed to the
> INFO   | jvm 1| 2016/04/20 09:30:25 |   application.
> ERROR  | wrapper  | 2016/04/20 09:30:27 | JVM exited while loading the
> application.
>
>
> --
> Jody Garnett
>
> On 18 April 2016 at 21:32, Jody Garnett  wrote:
>
>> Available for testing here:
>> - http://ares.boundlessgeo.com/geoserver/release/2.9-beta2/
>>
>> I am downloading and testing the DMG. Given the amount of changes in this
>> beta2 I would appreciate confirmation the application starts up (ie is
>> packaged correctly) on a range of platforms (linux, windows, etc...) before
>> we announce.
>> --
>> Jody Garnett
>>
>
> --
> Find and fix application performance issues faster with Applications
> Manager
> Applications Manager provides deep performance insights into multiple
> tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> ___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] [Geotools-devel] WFS Transaction XML parsing

[Justin Deoliveira]

Cool, yeah I think the TransactionPlugin could have some interesting uses
for sure, I think it’s kind of under utilized.

Re the user data attributes I think personally think it could be general
enough. The whole user data idea about shuffling attributes along that you
don’t want to model explicitly I think is pretty useful. And extending that
out to exchange formats like GML and JSON I think is just a natural
extension of that. Interested to hear how other devs feel.

On Fri, Apr 8, 2016 at 9:33 AM Jim Hughes <jn...@ccri.com> wrote:

> Hi Justin,
>
> Thanks.  I forgot to mention that I had seen the TransactionPlugin
> extension point; that one is awesome and I see how to use it support my
> second suggestion.
>
> Would changes in the GML2/3ParsingUtils to inject attributes into a
> SimpleFeature's userData be sensible / more broadly useful?  I'm a bit shy
> about pushing hard for such a change since I am not sure about any other
> ramifications.
>
> Thanks,
>
> Jim
>
>
> On 04/08/2016 10:45 AM, Justin Deoliveira wrote:
>
> Hey Jim,
>
> The wfs native element might be the cleanest way to handle this. I’ve seen
> folks use it before for security and validation type stuff with some
> success. In GeoServer you can plug in WFS transactions callbacks pretty
> easily using the TransactionPlugin extension point. It has direct access
> to the transaction object which has the native content on it.
>
> If you do want to go with approach (1): during GML parsing I don’t believe
> there is any way to tag a GML attribute as something you want to store in
> user data. Folks might correct me on that one though. To support it I
> wonder if we could do something simple like a custom attribute on the gml
> attribute element. Something like:
>
>  foo
>
> One potential downside might be validation… however in GeoServer last I
> checked we don’t validate features on the way in… mostly because it’s a
> pain to have to specify all the schema references properly so a parser can
> actually validate. It may also be there in the gml schema there is some
> attribute we might be able to use /abuse for this purpose… I can’t think of
> one off hand though.
>
> As far as I know the feature parsing logic still lives in the
> GML3ParsingUtils and GML2ParsingUtils classes. To add some support for
> putting an attribute in user data rather than a normal attribute I think
> you would be looking at modifying this method.
>
> As you’ll notice this only applies to simple features. If working with
> complex features i am actually not sure where that logic lives anymore. One
> of the app-schema folks can point you at that if need be.
>
> Hope that helps!
>
> -Justin
>
>
> On Fri, Apr 8, 2016 at 8:09 AM Jim Hughes <jn...@ccri.com> wrote:
>
>> Hi all,
>>
>> Apologies for the cross-post, but my question hits a little of how
>> GeoServer handles WFS transactions and a little bit of how GeoTools may
>> handle WFS/GML parsing.
>>
>> My high-level goal is to find a way to add security info to a WFS
>> transaction.  I can see three big options:  1. add some bits to the GML
>> feature / WFS call which would set a SimpleFeature's userData or
>> otherwise provide additional data, 2. leverage a WFS 'Native' tag, or 3.
>> store the security info in the SimpleFeature.
>>
>> I've got a pretty good handle on the last two options.  The first option
>> would provide the greatest flexibility, so I'm wondering if anyone can
>> help point me in the right direction there.  (Or otherwise say that this
>> is impossible without re-writing GT/GS XML handling...)
>>
>> Thanks in advance,
>>
>> Jim
>>
>>
>> --
>> ___
>> GeoTools-Devel mailing list
>> geotools-de...@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
>
>
--
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] [Geotools-devel] WFS Transaction XML parsing

[Justin Deoliveira]

Hey Jim,

The wfs native element might be the cleanest way to handle this. I’ve seen
folks use it before for security and validation type stuff with some
success. In GeoServer you can plug in WFS transactions callbacks pretty
easily using the TransactionPlugin
<[https://github.com/geoserver/geoserver/blob/master/src/wfs/src/main/java/org/geoserver/wfs/TransactionPlugin.java](https://github.com/geoserver/geoserver/blob/master/src/wfs/src/main/java/org/geoserver/wfs/TransactionPlugin.java>
extension point. It has direct access to the transaction object which has
the native content on it.

If you do want to go with approach (1): during GML parsing I don’t believe
there is any way to tag a GML attribute as something you want to store in
user data. Folks might correct me on that one though. To support it I
wonder if we could do something simple like a custom attribute on the gml
attribute element. Something like:

 foo

One potential downside might be validation… however in GeoServer last I
checked we don’t validate features on the way in… mostly because it’s a
pain to have to specify all the schema references properly so a parser can
actually validate. It may also be there in the gml schema there is some
attribute we might be able to use /abuse for this purpose… I can’t think of
one off hand though.

As far as I know the feature parsing logic still lives in the
GML3ParsingUtils and GML2ParsingUtils classes. To add some support for
putting an attribute in user data rather than a normal attribute I think
you would be looking at modifying this method
<[https://github.com/geotools/geotools/blob/master/modules/extension/xsd/xsd-gml2/src/main/java/org/geotools/gml2/bindings/GML2ParsingUtils.java#L338-L362](https://github.com/geotools/geotools/blob/master/modules/extension/xsd/xsd-gml2/src/main/java/org/geotools/gml2/bindings/GML2ParsingUtils.java#L338-L362>
.

As you’ll notice this only applies to simple features. If working with
complex features i am actually not sure where that logic lives anymore. One
of the app-schema folks can point you at that if need be.

Hope that helps!

-Justin


On Fri, Apr 8, 2016 at 8:09 AM Jim Hughes  wrote:

> Hi all,
>
> Apologies for the cross-post, but my question hits a little of how
> GeoServer handles WFS transactions and a little bit of how GeoTools may
> handle WFS/GML parsing.
>
> My high-level goal is to find a way to add security info to a WFS
> transaction.  I can see three big options:  1. add some bits to the GML
> feature / WFS call which would set a SimpleFeature's userData or
> otherwise provide additional data, 2. leverage a WFS 'Native' tag, or 3.
> store the security info in the SimpleFeature.
>
> I've got a pretty good handle on the last two options.  The first option
> would provide the greatest flexibility, so I'm wondering if anyone can
> help point me in the right direction there.  (Or otherwise say that this
> is impossible without re-writing GT/GS XML handling...)
>
> Thanks in advance,
>
> Jim
>
>
> --
> ___
> GeoTools-Devel mailing list
> geotools-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
--
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] spring 4 upgrade

[Justin Deoliveira]

More progress, updates inline.

On Mon, Mar 14, 2016 at 11:59 PM Christian Mueller <
christian.muel...@os-solutions.at> wrote:

> Hi Jody
>
> The CAS test setup is a rather complex one. You have to
>
> 1) Create a maven project producing a CAS overlay war file
> 2) Setup HTTPS  for the server (Generate key on the server side,import
> server certificate in cacerts)
> 3) Setup HTTPS for the client side (CAS server contacts the client using
> https for proxy granting tickets).
>
> Maybe the following cold work
>
> Add the overlay CAS war file as test resource.
> Search for a free TCP/IP port
> Start the war file using Jetty. Jetty must have the proper truststore and
> keystore configuration
> Start the tests with the proper  truststore and keystore configuration
> Shutdown Jetty.
>
> Does this make sense ?
>
> Christian
>
>
>
>
>
>
> On Tue, Mar 15, 2016 at 1:02 AM, Jody Garnett <jody.garn...@gmail.com>
> wrote:
>
>> Thanks Christian, I have updated the wiki page to reflect this progress:
>>
>> * https://github.com/geoserver/geoserver/wiki/Spring-4-Upgrade
>>
>> Trying to get a handle on what is left to do, especially testing. If
>> security-cas requires any additional testing please add it to the page
>> above.
>>
>> What we have remaining before beta2:
>>
>> 3. Migrate tests from mock runner to spring-test
>>(done) core building
>>(done)  extension building
>>(volunteer needed) community modules (-PcommunityRelease) could not
>> fix everything
>>
>
>From what I can tell everything was mostly done by Andrea. There was one
lingering reference in jms-cluster which I just pushed an update for.

>
>> 4. GWC - also uses spring and will require update
>>(done) Upgrade to Servlet 3.0
>>(kevin) Migrate from Acegi 1.0.7 to Spring Security
>>
>> 5. GeoFence Integration
>>(volunteer) needed
>>
>> 7. community modules (-PcommunityRelease)
>>need a list of these
>>
>
I just pushed another batch of changes that “fixes" most of the community
modules. The only remaining one is geofence? I assume an upgrade to spring
4 needs to take place somewhere upstream? Is that what (5) captures? I am
not at all familiar with geofence so not sure what needs to be done here.

By “fixes” I mean fixing errors that result from the spring upgrade. There
are still test failures in those modules but as I understand it we don’t
test those modules as part of the build correct? Anyways I haven’t verified
on master but the test failures appear to be unrelated to the upgrades.

>
>> 8. Merge feature branch, release 2.9-beta2
>>
>>
>> --
>> Jody Garnett
>>
>> On 13 March 2016 at 09:01, Christian Mueller <
>> christian.muel...@os-solutions.at> wrote:
>>
>>> Hi
>>>
>>> I have do done the the CAS Port and pushed the commit to
>>>  the spring4-upgrade branch.
>>>
>>> Cheers
>>>
>>>
>>> On Sun, Mar 13, 2016 at 5:20 AM, Jody Garnett <jody.garn...@gmail.com>
>>> wrote:
>>>
>>>> Do not worry about login/logout for GeoExplorer.
>>>>
>>>> However I think the endpoint may be used by others so we should supply
>>>> migration instructions for anyone else affected.
>>>>
>>>>
>>>>
>>>>
>>>> On Sat, Mar 12, 2016 at 12:32 PM Justin Deoliveira <jdeol...@gmail.com>
>>>> wrote:
>>>>
>>>>> An update on this one.
>>>>>
>>>>> Basically where it stands is that I think everything minus CAS has
>>>>> been ported over the new spring apis and afaik all tests are passing. I’ve
>>>>> run the server (with just the core modules) and can confirm that a quick
>>>>> smoke test doesn’t show any problems.
>>>>>
>>>>> In terms of compability issues the only issue I have found thus far is
>>>>> the issue with the spring security login endpoints changing (ie.
>>>>> /j_spring_security_check is now /login). It’s on my list to circle back to
>>>>> see if we can somehow change some config to use the old paths. However 
>>>>> when
>>>>> I looked before it didn’t look possible. I only know of one application
>>>>> (GeoExplorer) that utilizes the endpoints to login so i am not sure how 
>>>>> far
>>>>> reaching this issue actually is.
>>>>>
>>>>> So off the top of my head the remaining tasks are:
>>>>>
>>

Re: [Geoserver-devel] Sharing some user feedback about managing services per workspace

[Justin Deoliveira]

For what it’s worth a while back we identified this as a gap with virtual
services and when I discussed it with Gabriel he definitely agreed we
should allow gwc config to be local to a workspace, but that it was far
from a trivial effort.

On Mon, Mar 14, 2016 at 4:31 PM Jody Garnett  wrote:

> Kevin what is your though on this? What affects would it have on the gwc
> codebase? Or is it just an integration challenge...
>
> --
> Jody Garnett
>
> On 12 March 2016 at 04:34, Andrea Aime 
> wrote:
>
>> Hi,
>> I've been talking a bit with some users that are trying to have a single
>> GeoServer with several workspaces, one per application/department, each
>> providing some virtual services.
>>
>> One grievance they reported is how hard it is to transfer workspace
>> configurations
>> from test to production enviroments due to the gwc integration, and in
>> particular,
>> the gwc-layers.
>>
>> I was wondering, wouldn't it make sense to keep the gwc-layers folder
>> inside
>> the workspace, at least for layers/groups that are workspace specific?
>>
>> Checking, it seems the current design does not make it all that easy,
>> mostly because it's keeping everything keyed by tile layer id,
>> and that information by itself does not provide any clue about the
>> containing workspace, if any.
>>
>> I was wondering if anyone else has already investigated this issue?
>>
>> Cheers
>> Andrea
>>
>> --
>> ==
>> GeoServer Professional Services from the experts! Visit
>> http://goo.gl/it488V for more information.
>> ==
>>
>> Ing. Andrea Aime
>> @geowolf
>> Technical Lead
>>
>> GeoSolutions S.A.S.
>> Via di Montramito 3/A
>> 55054  Massarosa (LU)
>> 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.
>>
>> ---
>>
>>
>> --
>> Transform Data into Opportunity.
>> Accelerate data analysis in your applications with
>> Intel Data Analytics Acceleration Library.
>> Click to learn more.
>> http://pubads.g.doubleclick.net/gampad/clk?id=278785111=/4140
>> ___
>> Geoserver-devel mailing list
>> Geoserver-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>
>>
>
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785231=/4140
> ___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.

Re: [Geoserver-devel] Freeze for 2.9

[Justin Deoliveira]

Sounds good. And to be clear I wasn’t advocating for a freeze or
non-freeze, just asking the question so that I don’t commit something by
mistake.

On Mon, Mar 14, 2016 at 9:24 AM Jody Garnett  wrote:

> Looks like it is a non-issue, the vast majority of the spring4 migration
> is done (thanks Justin, Kevin and Christian) and we now have testing to do.
>
> If I get the word from Justin I will make a beta2 this week, and we can
> get back on the release train ... looking something like:
>
> - 17 March 2.9-beta2
> - 31 March 2.9-RC1
>
> To answer your question Justin, we would make a new master branch for the
> RC1.
>
> --
> Jody Garnett
>
> On 14 March 2016 at 05:51, Simone Giannecchini <
> simone.giannecch...@geo-solutions.it> wrote:
>
>> Dear All,
>> I have talked to Andrea about whether or not we should unfreeze 2.9
>> given the delay for the upgrade to spring 4.
>>
>> >From the perspective of someone who follows clients deployments, I am
>> against unfreezing 2.9.
>> With the delay for 2.9 we are making room for a change which is major
>> (at least in the eyes of the users) and piling more changes on top
>> would defeat this delay, a simple as that.
>>
>> I understand the push for releasing paid work, but I care more about
>> stability.
>>
>> Open to see what others think.
>>
>> Regards,
>> Simone Giannecchini
>> ==
>> GeoServer Professional Services from the experts!
>> Visit http://goo.gl/it488V for more information.
>> ==
>> Ing. Simone Giannecchini
>> @simogeo
>> Founder/Director
>>
>> GeoSolutions S.A.S.
>> Via di Montramito 3/A
>> 55054  Massarosa (LU)
>> Italy
>> phone: +39 0584 962313
>> fax: +39 0584 1660272
>> mob:   +39 333 8128928
>>
>> 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.
>>
>>
>> --
>> Transform Data into Opportunity.
>> Accelerate data analysis in your applications with
>> Intel Data Analytics Acceleration Library.
>> Click to learn more.
>> http://pubads.g.doubleclick.net/gampad/clk?id=278785231=/4140
>> ___
>> Geoserver-devel mailing list
>> Geoserver-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>
>
>
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785231=/4140
> ___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231=/4140___
Geoserver-devel mailing list

Re: [Geoserver-devel] spring 4 upgrade

[Justin Deoliveira]

Great, thanks Chris. I would have to say I agree so unless someone else has
a strong opinion on this one I vote we go with this approach.

On Mon, Mar 14, 2016 at 8:34 AM Chris Snider <chris.sni...@issinc.com>
wrote:

> Justin,
>
>
>
> For us it is a simple change to a wrapping HTML page.  It doesn’t make
> sense for us to have the added complexity to trap the old endpoint to the
> new endpoint since we end up redirecting the browser to a completely
> different service endpoint that supports our overall single sign on process.
>
>
>
> I would vote to simply take in the new endpoint and update applicable
> front ends that need to do something special.
>
>
>
> Chris Snider
>
> Senior Software Engineer
>
> *Intelligent Software Solutions, Inc.*
>
> [image: Description: Description: Description:
> cid:image001.png@01CA1F1F.CBC93990]
>
>
>
> *From:* Justin Deoliveira [mailto:jdeol...@gmail.com]
> *Sent:* Monday, March 14, 2016 8:28 AM
> *To:* Chris Snider <chris.sni...@issinc.com>; Jody Garnett <
> jody.garn...@gmail.com>; Christian Mueller <
> christian.muel...@os-solutions.at>
>
>
> *Cc:* Geoserver Developers <geoserver-devel@lists.sourceforge.net>
> *Subject:* Re: [Geoserver-devel] spring 4 upgrade
>
>
>
> Hey Chris,
>
>
>
> Thanks for the info. If we added a redirect from /j_spring_security_check
> to the new endpoint do you think that would help much? I’m trying to guage
> whether it’s worth the added complexity or if this is just something we can
> document as part of the upgrade.
>
>
>
> -Justin
>
>
>
> On Mon, Mar 14, 2016 at 7:29 AM Chris Snider <chris.sni...@issinc.com>
> wrote:
>
> Hi,
>
>
>
> I know we trap for the j_spring_security_check using JavaScript on page
> load to redirect the logout to our authentication server.  If this changes,
> we just need to update our scripts.  If there is a configuration update we
> have to do to maintain the current endpoint, I’m ok with that as well.
>
>
>
> Thanks for getting the Spring 4 upgrade accomplished…it will help us
> immensely.
>
>
>
> Chris Snider
>
> Senior Software Engineer
>
> *Intelligent Software Solutions, Inc.*
>
> [image: Description: Description: Description:
> cid:image001.png@01CA1F1F.CBC93990]
>
>
>
> *From:* Jody Garnett [mailto:jody.garn...@gmail.com]
> *Sent:* Saturday, March 12, 2016 9:20 PM
> *To:* Justin Deoliveira <jdeol...@gmail.com>; Christian Mueller <
> christian.muel...@os-solutions.at>
> *Cc:* Geoserver Developers <geoserver-devel@lists.sourceforge.net>
> *Subject:* Re: [Geoserver-devel] spring 4 upgrade
>
>
>
> Do not worry about login/logout for GeoExplorer.
>
> However I think the endpoint may be used by others so we should supply
> migration instructions for anyone else affected.
>
>
> On Sat, Mar 12, 2016 at 12:32 PM Justin Deoliveira <jdeol...@gmail.com>
> wrote:
>
> An update on this one.
>
>
>
> Basically where it stands is that I think everything minus CAS has been
> ported over the new spring apis and afaik all tests are passing. I’ve run
> the server (with just the core modules) and can confirm that a quick smoke
> test doesn’t show any problems.
>
>
>
> In terms of compability issues the only issue I have found thus far is the
> issue with the spring security login endpoints changing (ie.
> /j_spring_security_check is now /login). It’s on my list to circle back to
> see if we can somehow change some config to use the old paths. However when
> I looked before it didn’t look possible. I only know of one application
> (GeoExplorer) that utilizes the endpoints to login so i am not sure how far
> reaching this issue actually is.
>
>
>
> So off the top of my head the remaining tasks are:
>
>
>
> - Port CAS
>
> - Look at the login/logout endpoint issue
>
> - Decide what to do about the login/logout issue if we can’t change them
> back
>
> - Do some more general and thorough testing
>
>
>
>
>
>
>
> On Fri, Mar 4, 2016 at 12:19 PM Jody Garnett <jody.garn...@gmail.com>
> wrote:
>
> Thanks Christian, I will write up the blog post - and talk to you all next
> week with respect to planning.
>
>
> --
>
> Jody Garnett
>
>
>
> On 3 March 2016 at 23:24, Christian Mueller <
> christian.muel...@os-solutions.at> wrote:
>
> Hi all
>
>
>
> I think it is necessary to upgrade, +1 here. I have seen Justin created a
> branch spring4-upgrade fixing the broken security code.
>
>
>
> For CAS I have an online test scenario.
>
>
>
> Cheers
>
>
>
>
>

Re: [Geoserver-devel] Freeze for 2.9

[Justin Deoliveira]

I know I don’t get a vote since I am no longer PSC but as somone who
contributes more than just bug fixes to the code base would this mean there
would no longer be a branch open for new features until 2.9 branches off?

On Mon, Mar 14, 2016 at 5:54 AM Simone Giannecchini <
simone.giannecch...@geo-solutions.it> wrote:

> Dear All,
> I have talked to Andrea about whether or not we should unfreeze 2.9
> given the delay for the upgrade to spring 4.
>
> From the perspective of someone who follows clients deployments, I am
> against unfreezing 2.9.
> With the delay for 2.9 we are making room for a change which is major
> (at least in the eyes of the users) and piling more changes on top
> would defeat this delay, a simple as that.
>
> I understand the push for releasing paid work, but I care more about
> stability.
>
> Open to see what others think.
>
> Regards,
> Simone Giannecchini
> ==
> GeoServer Professional Services from the experts!
> Visit http://goo.gl/it488V for more information.
> ==
> Ing. Simone Giannecchini
> @simogeo
> Founder/Director
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054  Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob:   +39  333 8128928
>
> 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.
>
>
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785231=/4140
> ___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231=/4140___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] spring 4 upgrade

[Justin Deoliveira]

Hey Chris,

Thanks for the info. If we added a redirect from /j_spring_security_check
to the new endpoint do you think that would help much? I’m trying to guage
whether it’s worth the added complexity or if this is just something we can
document as part of the upgrade.

-Justin

On Mon, Mar 14, 2016 at 7:29 AM Chris Snider <chris.sni...@issinc.com>
wrote:

> Hi,
>
>
>
> I know we trap for the j_spring_security_check using JavaScript on page
> load to redirect the logout to our authentication server.  If this changes,
> we just need to update our scripts.  If there is a configuration update we
> have to do to maintain the current endpoint, I’m ok with that as well.
>
>
>
> Thanks for getting the Spring 4 upgrade accomplished…it will help us
> immensely.
>
>
>
> Chris Snider
>
> Senior Software Engineer
>
> *Intelligent Software Solutions, Inc.*
>
> [image: Description: Description: Description:
> cid:image001.png@01CA1F1F.CBC93990]
>
>
>
> *From:* Jody Garnett [mailto:jody.garn...@gmail.com]
> *Sent:* Saturday, March 12, 2016 9:20 PM
> *To:* Justin Deoliveira <jdeol...@gmail.com>; Christian Mueller <
> christian.muel...@os-solutions.at>
> *Cc:* Geoserver Developers <geoserver-devel@lists.sourceforge.net>
> *Subject:* Re: [Geoserver-devel] spring 4 upgrade
>
>
>
> Do not worry about login/logout for GeoExplorer.
>
> However I think the endpoint may be used by others so we should supply
> migration instructions for anyone else affected.
>
>
>
> On Sat, Mar 12, 2016 at 12:32 PM Justin Deoliveira <jdeol...@gmail.com>
> wrote:
>
> An update on this one.
>
>
>
> Basically where it stands is that I think everything minus CAS has been
> ported over the new spring apis and afaik all tests are passing. I’ve run
> the server (with just the core modules) and can confirm that a quick smoke
> test doesn’t show any problems.
>
>
>
> In terms of compability issues the only issue I have found thus far is the
> issue with the spring security login endpoints changing (ie.
> /j_spring_security_check is now /login). It’s on my list to circle back to
> see if we can somehow change some config to use the old paths. However when
> I looked before it didn’t look possible. I only know of one application
> (GeoExplorer) that utilizes the endpoints to login so i am not sure how far
> reaching this issue actually is.
>
>
>
> So off the top of my head the remaining tasks are:
>
>
>
> - Port CAS
>
> - Look at the login/logout endpoint issue
>
> - Decide what to do about the login/logout issue if we can’t change them
> back
>
> - Do some more general and thorough testing
>
>
>
>
>
>
>
> On Fri, Mar 4, 2016 at 12:19 PM Jody Garnett <jody.garn...@gmail.com>
> wrote:
>
> Thanks Christian, I will write up the blog post - and talk to you all next
> week with respect to planning.
>
>
> --
>
> Jody Garnett
>
>
>
> On 3 March 2016 at 23:24, Christian Mueller <
> christian.muel...@os-solutions.at> wrote:
>
> Hi all
>
>
>
> I think it is necessary to upgrade, +1 here. I have seen Justin created a
> branch spring4-upgrade fixing the broken security code.
>
>
>
> For CAS I have an online test scenario.
>
>
>
> Cheers
>
>
>
>
>
>
>
> On Thu, Mar 3, 2016 at 6:19 PM, Jody Garnett <jody.garn...@gmail.com>
> wrote:
>
> Thanks Simone, updating the page. I will give Christian another day and
> then I would like to start making plans.
>
>
> --
>
> Jody Garnett
>
>
>
> On 3 March 2016 at 09:16, Simone Giannecchini <
> simone.giannecch...@geo-solutions.it> wrote:
>
> Ciao Jody,
> I am for upgrading to Spring 4 + delaying the release.
>
> I already told Andrea we can devote resources to help with the upgrade.
>
>
> Regards,
> Simone Giannecchini
> ==
> GeoServer Professional Services from the experts!
> Visit http://goo.gl/it488V for more information.
> ==
> Ing. Simone Giannecchini
> @simogeo
> Founder/Director
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054  Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob:   +39 333 8128928 <%2B39%20%20333%208128928>
>
> 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 fi

Re: [Geoserver-devel] spring 4 upgrade

[Justin Deoliveira]

An update on this one.

Basically where it stands is that I think everything minus CAS has been
ported over the new spring apis and afaik all tests are passing. I’ve run
the server (with just the core modules) and can confirm that a quick smoke
test doesn’t show any problems.

In terms of compability issues the only issue I have found thus far is the
issue with the spring security login endpoints changing (ie.
/j_spring_security_check is now /login). It’s on my list to circle back to
see if we can somehow change some config to use the old paths. However when
I looked before it didn’t look possible. I only know of one application
(GeoExplorer) that utilizes the endpoints to login so i am not sure how far
reaching this issue actually is.

So off the top of my head the remaining tasks are:

- Port CAS
- Look at the login/logout endpoint issue
- Decide what to do about the login/logout issue if we can’t change them
back
- Do some more general and thorough testing



On Fri, Mar 4, 2016 at 12:19 PM Jody Garnett  wrote:

> Thanks Christian, I will write up the blog post - and talk to you all next
> week with respect to planning.
>
> --
> Jody Garnett
>
> On 3 March 2016 at 23:24, Christian Mueller <
> christian.muel...@os-solutions.at> wrote:
>
>> Hi all
>>
>> I think it is necessary to upgrade, +1 here. I have seen Justin created a
>> branch spring4-upgrade fixing the broken security code.
>>
>> For CAS I have an online test scenario.
>>
>> Cheers
>>
>>
>>
>> On Thu, Mar 3, 2016 at 6:19 PM, Jody Garnett 
>> wrote:
>>
>>> Thanks Simone, updating the page. I will give Christian another day and
>>> then I would like to start making plans.
>>>
>>> --
>>> Jody Garnett
>>>
>>> On 3 March 2016 at 09:16, Simone Giannecchini <
>>> simone.giannecch...@geo-solutions.it> wrote:
>>>
 Ciao Jody,
 I am for upgrading to Spring 4 + delaying the release.

 I already told Andrea we can devote resources to help with the upgrade.


 Regards,
 Simone Giannecchini
 ==
 GeoServer Professional Services from the experts!
 Visit http://goo.gl/it488V for more information.
 ==
 Ing. Simone Giannecchini
 @simogeo
 Founder/Director

 GeoSolutions S.A.S.
 Via di Montramito 3/A
 55054  Massarosa (LU)
 Italy
 phone: +39 0584 962313
 fax: +39 0584 1660272
 mob:   +39 333 8128928

 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.


 On Thu, Mar 3, 2016 at 6:04 PM, Jody Garnett 
 wrote:
 > Thanks Brad, updated the table accordingly.  I probably should of
 phrased
 > this as a yes/no question.
 >
 > We are waiting on two PSC members:
 > - Christian Mueller
 > - Simone Giannecchini
 >
 > --
 > Jody Garnett
 >
 > On 3 March 2016 at 06:18, Brad Hards  wrote:
 >>
 >> On Thu, 3 Mar 2016 06:08:39 PM Ben Caradoc-Davies wrote:
 >> > Thank you so much Jody for all your work rounding this up.
 >> >
 

Re: [Geoserver-devel] Proposal: GeoServer Resource Browser GUI

[Justin Deoliveira]

I’ll reply to the spring4 thread with the latest.

On Thu, Mar 10, 2016 at 1:32 PM Jody Garnett  wrote:

> My understanding is that the code freeze is off, schedule updated to
> include a second beta (which would start a new code freeze), testing and
> then a RC (which would start a new master).
>
> See "schedule" -
> https://github.com/geoserver/geoserver/wiki/Spring-4-Upgrade
>
> What is unknown to me is the timeframe - so I am watching daily for news
> from Kevin and Justin.
>
>
> --
> Jody Garnett
>
> On 10 March 2016 at 12:01, Andrea Aime 
> wrote:
>
>> On Thu, Mar 10, 2016 at 8:15 PM, Jody Garnett 
>> wrote:
>>
>>> Thought you covered this when discussing change to release schedule. It
>>> sounds like the spring 4 upgrade is going smoothly thus far.
>>>
>>
>> So, you confirm you think that anything goes?
>>
>> Cheers
>> Andrea
>>
>> --
>> ==
>> GeoServer Professional Services from the experts! Visit
>> http://goo.gl/it488V for more information.
>> ==
>>
>> Ing. Andrea Aime
>> @geowolf
>> Technical Lead
>>
>> GeoSolutions S.A.S.
>> Via di Montramito 3/A
>> 55054  Massarosa (LU)
>> 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.
>>
>> ---
>>
>
>
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785111=/4140
> ___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111=/4140___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Progress on spring upgrade

[Justin Deoliveira]

Thanks Andrea. Comments inline.

On Sun, Mar 6, 2016 at 3:00 AM Andrea Aime <andrea.a...@geo-solutions.it>
wrote:

> Hi Justin,
> had a very quick look, GeoServer wise the only thing I noticed was the
> lack of header upgrades (which
> can be done later), all the other changes look reasonable (but mind, I
> haven't used Spring 4 anywhere else).
>
>
> On Sat, Mar 5, 2016 at 6:23 PM, Justin Deoliveira <jdeol...@gmail.com>
> wrote:
>
>> Hey folks, thought I would send a quick update on progress. To recap the
>> branch currently being worked on is here:
>>
>>https://github.com/geoserver/geoserver/tree/spring4-upgrade
>>
>> The branch currently contains:
>>
>>   - Core upgrades to spring 4.2.5 and spring security 4.0.4
>>   - Upgrade to servlet api 3.0.1
>>   - Andreas work to migrate from mockrunner to spring-test
>>
>> I also pushed a branch for geowebcache:
>>
>>   https://github.com/GeoWebCache/geowebcache/tree/spring-servlet-upgrade
>>
>
> Tried to build this one, I get a failure in gwc-wmts:
>
> Tests run: 6, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 11.632 sec
> <<< FAILURE!
> testGetTileWithStyle(org.geowebcache.service.wmts.WMTSServiceTest)  Time
> elapsed: 0.416 sec  <<< FAILURE!
> java.lang.AssertionError:
> Expected: map containing ["STYLES"->"Bar"]
>  but: map was []
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:8)
> at
> org.geowebcache.service.wmts.WMTSServiceTest.testGetTileWithStyle(WMTSServiceTest.java:524)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at junit.framework.TestCase.runBare(TestCase.java:141)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.framework.TestResult.run(TestResult.java:125)
> at junit.framework.TestCase.run(TestCase.java:129)
> at junit.framework.TestSuite.runTest(TestSuite.java:255)
> at junit.framework.TestSuite.run(TestSuite.java:250)
> at
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
>
> It was a simple fix for a mock expectation, so I've fixed it. One liner
> change pushed to the branch.
>

Nice, thanks!

>
>
>>
>> Although it looks like Kevin already did the work here?:
>>
>>   https://github.com/GeoWebCache/geowebcache/tree/spring4-upgrade
>>
>
> Looks like this one misses the servlet api upgrade though.
>
>
>>
>>
>> At any rate, one of those branches will be required to build the
>> geoserver branch.
>>
>> At the moment all the core modules compile and pass tests. With the
>> exception of one wms test that from what I can tell was some wierd osx
>> failure. It would be nice if someone else could verify that though.
>>
>
> No failures in wms here (also made a fresh build of geotools to be on the
> safe side), do you have details?
> I've made a full build and I have failures in the following extensions:
> CAS (expected), WPS, XSLT, monitoring hibernate... not all
> that many in the end.
> Assuming you're not working on it right now, I'm going to have a quick
> look.
>
>
I’ve attached the failure trace I get
from testCoverageViewMap(org.geoserver.wm

[Geoserver-devel] Progress on spring upgrade

[Justin Deoliveira]

Hey folks, thought I would send a quick update on progress. To recap the
branch currently being worked on is here:

   https://github.com/geoserver/geoserver/tree/spring4-upgrade

The branch currently contains:

  - Core upgrades to spring 4.2.5 and spring security 4.0.4
  - Upgrade to servlet api 3.0.1
  - Andreas work to migrate from mockrunner to spring-test

I also pushed a branch for geowebcache:

  https://github.com/GeoWebCache/geowebcache/tree/spring-servlet-upgrade

Although it looks like Kevin already did the work here?:

  https://github.com/GeoWebCache/geowebcache/tree/spring4-upgrade

At any rate, one of those branches will be required to build the geoserver
branch.

At the moment all the core modules compile and pass tests. With the
exception of one wms test that from what I can tell was some wierd osx
failure. It would be nice if someone else could verify that though.

I’ve also run the server and everythign starts up ok, but I haven’t poked
it much harder than a quick smoke test.

There is one interesting thing that I found with spring security. The login
and logout endpoints have changed. So “/j_spring_security_check" is now
“/login” and “/j_spring_security_logout” is now “/logout”. I’m still unsure
what the backwards compatability repercussions will be with this. It looks
like those paths are configurable in some places (like if using annotation
based config) but the way we are using some of the filters it didn’t look
like they were. I was going to circle back to this.

So… next steps is to start updating extensions and community modules. The
big one being cas. @Christian: I think you have all you need on that branch
to start looking at the CAS migration. Let me know if you have any
questions.

That’s about it for now.

-Justin
--
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] spring 4 upgrade

[Justin Deoliveira]

Sure, just pushed the branch it to the geoserver repo.

On Wed, Mar 2, 2016 at 11:50 AM Jody Garnett <jody.garn...@gmail.com> wrote:

> Sounds good, want to make a geoserver branch. And thanks for getting
> things started, Kevin also did some research/experiment and may have a
> contribution.
>


>
> Still waiting on PSC votes.
> On Wed, Mar 2, 2016 at 10:25 AM Justin Deoliveira <jdeol...@gmail.com>
> wrote:
>
>> I took the liberty of starting down the road of this described approach.
>> I’ve gotten it to the point where all of the core modules compile (haven’t
>> taken on extensions or community modules) against spring 4.2.5 and spring
>> security 4.0.4. Haven’t actually run the server or any tests yet.
>>
>>   https://github.com/jdeolive/geoserver/tree/spring4-upgrade
>>
>> I think the next step would be to merge this with andreas mockrunner
>> branch and go ahead and perform the servlet api upgrade. With that done I
>> think we would be in a position to start working through all of the unit
>> tests.
>>
>>
>> On Wed, Mar 2, 2016 at 8:10 AM Justin Deoliveira <jdeol...@gmail.com>
>> wrote:
>>
>>> The core api changes around ProviderManager and FilterChainProxy I think
>>> is something that won’t be too crazy to work around. I think the best bet
>>> there will be to have the geoserver counter parts
>>> (GeoServerSecurityManager, GeoServerFilterChainProxy) wrap the spring stuff
>>> rather than extend it. That way it can be recreated as needed via
>>> constructor rather than setters after the fact. In an ideal world nothing
>>> around thsoe classes would have to change, but that is probalby a bit too
>>> optimistic :)
>>>
>>> As for the CAS stuff you’re guess is as good as mine. I can confirm
>>> Christians findings that the api has changed significantly and from what I
>>> can tell without much guidance as to what the transition is from the old
>>> api to the new.  Could potentially be looking at a re-implementation there
>>> but knowing next to nothing about CAS I delegate to Christian on that.
>>>
>>>
>>>
>>> On Wed, Mar 2, 2016 at 12:16 AM Christian Mueller <
>>> christian.muel...@os-solutions.at> wrote:
>>>
>>>> Hi all
>>>>
>>>> The Spring security API changed since 4.x.  GeoServer is relying on
>>>> getters and setters and this methods are gone. Since 4.x, the instance
>>>> variables are set using a constructor. Not easy to change.
>>>>
>>>> Additionally,  the CAS java client also changed the public API, this is
>>>> the second problem because the CAS jar is a dependency of Spring Security.
>>>>
>>>> Will have a look at the problem during the weekend.
>>>>
>>>> Do we have a branch where I can start investigating ?
>>>>
>>>> Cheers
>>>> Christian
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, Mar 2, 2016 at 4:29 AM, Andrea Aime <
>>>> andrea.a...@geo-solutions.it> wrote:
>>>>
>>>>> Hi Jody,
>>>>> as said in the meeting, I'm supportive of a delay long enough to switch
>>>>> everything to Spring 4 and make it solid (2-3 months)
>>>>>
>>>>> Cheers
>>>>> Andrea
>>>>>
>>>>>
>>>>> On Wed, Mar 2, 2016 at 2:49 AM, Jody Garnett <jody.garn...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Okay, I respect both options making this a tough decision. I wish we
>>>>>> could hear back from Christian about the security-cas release, but the 
>>>>>> same
>>>>>> spring4 migration needed by both plans.
>>>>>>
>>>>>> I would like to go ahead with the release delay (do the spring 4
>>>>>> upgrade now), avoids an awkward 50% solution that we would need to 
>>>>>> support.
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Site24x7 APM Insight: Get Deep Visibility into Application Performance
>>>>>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>>>>>> Monitor end-to-end web transactions and take corrective actions now
>>>>>> Troubleshoot faster and im

Re: [Geoserver-devel] spring 4 upgrade

[Justin Deoliveira]

I took the liberty of starting down the road of this described approach.
I’ve gotten it to the point where all of the core modules compile (haven’t
taken on extensions or community modules) against spring 4.2.5 and spring
security 4.0.4. Haven’t actually run the server or any tests yet.

  https://github.com/jdeolive/geoserver/tree/spring4-upgrade

I think the next step would be to merge this with andreas mockrunner branch
and go ahead and perform the servlet api upgrade. With that done I think we
would be in a position to start working through all of the unit tests.


On Wed, Mar 2, 2016 at 8:10 AM Justin Deoliveira <jdeol...@gmail.com> wrote:

> The core api changes around ProviderManager and FilterChainProxy I think
> is something that won’t be too crazy to work around. I think the best bet
> there will be to have the geoserver counter parts
> (GeoServerSecurityManager, GeoServerFilterChainProxy) wrap the spring stuff
> rather than extend it. That way it can be recreated as needed via
> constructor rather than setters after the fact. In an ideal world nothing
> around thsoe classes would have to change, but that is probalby a bit too
> optimistic :)
>
> As for the CAS stuff you’re guess is as good as mine. I can confirm
> Christians findings that the api has changed significantly and from what I
> can tell without much guidance as to what the transition is from the old
> api to the new.  Could potentially be looking at a re-implementation there
> but knowing next to nothing about CAS I delegate to Christian on that.
>
>
>
> On Wed, Mar 2, 2016 at 12:16 AM Christian Mueller <
> christian.muel...@os-solutions.at> wrote:
>
>> Hi all
>>
>> The Spring security API changed since 4.x.  GeoServer is relying on
>> getters and setters and this methods are gone. Since 4.x, the instance
>> variables are set using a constructor. Not easy to change.
>>
>> Additionally,  the CAS java client also changed the public API, this is
>> the second problem because the CAS jar is a dependency of Spring Security.
>>
>> Will have a look at the problem during the weekend.
>>
>> Do we have a branch where I can start investigating ?
>>
>> Cheers
>> Christian
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Mar 2, 2016 at 4:29 AM, Andrea Aime <andrea.a...@geo-solutions.it
>> > wrote:
>>
>>> Hi Jody,
>>> as said in the meeting, I'm supportive of a delay long enough to switch
>>> everything to Spring 4 and make it solid (2-3 months)
>>>
>>> Cheers
>>> Andrea
>>>
>>>
>>> On Wed, Mar 2, 2016 at 2:49 AM, Jody Garnett <jody.garn...@gmail.com>
>>> wrote:
>>>
>>>> Okay, I respect both options making this a tough decision. I wish we
>>>> could hear back from Christian about the security-cas release, but the same
>>>> spring4 migration needed by both plans.
>>>>
>>>> I would like to go ahead with the release delay (do the spring 4
>>>> upgrade now), avoids an awkward 50% solution that we would need to support.
>>>>
>>>>
>>>> --
>>>> Site24x7 APM Insight: Get Deep Visibility into Application Performance
>>>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>>>> Monitor end-to-end web transactions and take corrective actions now
>>>> Troubleshoot faster and improve end-user experience. Signup Now!
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
>>>> ___
>>>> Geoserver-devel mailing list
>>>> Geoserver-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>>>
>>>>
>>>
>>>
>>> --
>>> ==
>>> GeoServer Professional Services from the experts! Visit
>>> http://goo.gl/it488V for more information.
>>> ==
>>>
>>> Ing. Andrea Aime
>>> @geowolf
>>> Technical Lead
>>>
>>> GeoSolutions S.A.S.
>>> Via di Montramito 3/A
>>> 55054  Massarosa (LU)
>>> 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 d

Re: [Geoserver-devel] spring 4 upgrade

[Justin Deoliveira]

The core api changes around ProviderManager and FilterChainProxy I think is
something that won’t be too crazy to work around. I think the best bet
there will be to have the geoserver counter parts
(GeoServerSecurityManager, GeoServerFilterChainProxy) wrap the spring stuff
rather than extend it. That way it can be recreated as needed via
constructor rather than setters after the fact. In an ideal world nothing
around thsoe classes would have to change, but that is probalby a bit too
optimistic :)

As for the CAS stuff you’re guess is as good as mine. I can confirm
Christians findings that the api has changed significantly and from what I
can tell without much guidance as to what the transition is from the old
api to the new.  Could potentially be looking at a re-implementation there
but knowing next to nothing about CAS I delegate to Christian on that.



On Wed, Mar 2, 2016 at 12:16 AM Christian Mueller <
christian.muel...@os-solutions.at> wrote:

> Hi all
>
> The Spring security API changed since 4.x.  GeoServer is relying on
> getters and setters and this methods are gone. Since 4.x, the instance
> variables are set using a constructor. Not easy to change.
>
> Additionally,  the CAS java client also changed the public API, this is
> the second problem because the CAS jar is a dependency of Spring Security.
>
> Will have a look at the problem during the weekend.
>
> Do we have a branch where I can start investigating ?
>
> Cheers
> Christian
>
>
>
>
>
>
>
>
>
>
> On Wed, Mar 2, 2016 at 4:29 AM, Andrea Aime 
> wrote:
>
>> Hi Jody,
>> as said in the meeting, I'm supportive of a delay long enough to switch
>> everything to Spring 4 and make it solid (2-3 months)
>>
>> Cheers
>> Andrea
>>
>>
>> On Wed, Mar 2, 2016 at 2:49 AM, Jody Garnett 
>> wrote:
>>
>>> Okay, I respect both options making this a tough decision. I wish we
>>> could hear back from Christian about the security-cas release, but the same
>>> spring4 migration needed by both plans.
>>>
>>> I would like to go ahead with the release delay (do the spring 4 upgrade
>>> now), avoids an awkward 50% solution that we would need to support.
>>>
>>>
>>> --
>>> Site24x7 APM Insight: Get Deep Visibility into Application Performance
>>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>>> Monitor end-to-end web transactions and take corrective actions now
>>> Troubleshoot faster and improve end-user experience. Signup Now!
>>> http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
>>> ___
>>> Geoserver-devel mailing list
>>> Geoserver-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>>
>>>
>>
>>
>> --
>> ==
>> GeoServer Professional Services from the experts! Visit
>> http://goo.gl/it488V for more information.
>> ==
>>
>> Ing. Andrea Aime
>> @geowolf
>> Technical Lead
>>
>> GeoSolutions S.A.S.
>> Via di Montramito 3/A
>> 55054  Massarosa (LU)
>> 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 

Re: [Geoserver-devel] Python extension

[Justin Deoliveira]

Hi.

The existing python module was removed from the codebase recently, but the
docs appear to have stuck around. I’ll remove those shortly. The scripting
module is the recommended way to go, it covers most of what the existing
python module did. The new module is a more generic version that is meant
to work with languages other than python that are also supported on the jvm
such as javascript, groovy, ruby, etc…

If you look at the code you’ll find the module is broken up into many sub
modules based on language.

  https://github.com/geoserver/geoserver/tree/master/src/community/script

Hope that helps.

-Justin





On Fri, Feb 26, 2016 at 3:14 AM Ludvig Forslund 
wrote:

> Hi developers,
>
> I'm new to geoserver development and this might seem like a dumb question.
> I'm having troubles finding the python extension for geoserver explained
> here:
>
> http://docs.geoserver.org/stable/en/user/community/python/index.html
>
> I am able to find the scripting extension from the nightly builds here:
>
>
> http://docs.geoserver.org/stable/en/user/community/scripting/installation.html
>
> But I suppose this is not what I'm looking for. What's the difference
> between the two?
>
> Kind regards
> Ludvig
>
> --
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
> ___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] java 8, spring asm compatibility troubles...

[Justin Deoliveira]

If I recall correctly upgrading to any 4.x version will be an issue because
of spring security. See past email for the details. If my poor memory
serves me right I tried upgrading to 4.0.x or 4.2.x and ran into an issue
with security. Upgrading that to even 3.2.x led to issues previously
discussed.


On Wed, Feb 24, 2016 at 5:30 PM Jody Garnett  wrote:

> So if upgrading to spring 4.0.3 is the earliest feasible version, what
> else is around ... spring 4.2.4 is current.
>
> Justin had some notes on Oct 23rd on upgrading spring:
>
> Hey folks,
>> I am working on a project where I need to integrate some custom code into
>> GeoServer that requires a newer version of spring than is currently
>> used.  I was wondering if anyone would be opposed to a spring upgrade on
>> master?
>> If not, then the question becomes what to upgrade to? Currently the code
>> base depends on spring 3.1.x. The current release of spring is 4.2.x. I
>> haven’t explored how much work upgrading to 4.2.x will be but a while
>> back I did look at upgrading to 3.2.x and the changes were pretty simple.
>> My vote (fwiw) would be to explore the upgrade to 4.2.x and if we
>> encounter any blockers potentially upgrade to 3.2.x for the time being.
>> Let me know what y’all think.
>> Thanks!
>> -Justin
>
>
>
> --
> Jody Garnett
>
> On 24 February 2016 at 16:00, Kevin Smith  wrote:
>
>> From what I can see, simply having Java 8 bytecode as a target  opens up
>> this problem. Using Java 8 specific language constructs (Lambdas, etc)
>> merely makes problems more likely to manifest, as I found while doing some
>> work on GeoWebCache.  This is an assortment of horrifically obtuse looking
>> bugs waiting to happen.
>>
>> spring-asm is a dependency of spring-core so it could be potentially
>> being used anywhere spring is.
>>
>> --
>>   Kevin Michael Smith
>>   smit...@draconic.ca
>>
>>
>> On Wed, Feb 24, 2016, at 03:50 PM, Jody Garnett wrote:
>>
>> Kevin has been bashing his head against a very complicated failure today
>> ...
>>
>> Spring asm is repackaging of asm  (bytecode
>> manipulation and analysis framework). It is tripping over itself as Kevin
>> gleefully tries out Java 8 features like streams.
>>
>> GWC uses spring 3.1.1, the nearest release compatible with Java 8 seems
>> to be:
>>
>> *Spring 4.0.3*
>> 
>> *It’s my pleasure to announce that Spring Framework 4.0.3 is available.
>> This is the first release of the framework after Java 8’s launch last week;
>> it is built with OpenJDK 8 GA now and includes the latest ASM 5.0.1 (with
>> bytecode support at the JDK 8 GA level as well, superseding the custom ASM
>> 4.2 fork that we were previously using).*
>>
>>
>> TLDR: Not sure we are Java 8 ready yet
>> --
>> Jody Garnett
>>
>> --
>> Site24x7 APM Insight: Get Deep Visibility into Application Performance
>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>> Monitor end-to-end web transactions and take corrective actions now
>> Troubleshoot faster and improve end-user experience. Signup Now!
>> http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
>> *___*
>> Geoserver-devel mailing list
>> Geoserver-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>
>>
>>
>>
>> --
>> Site24x7 APM Insight: Get Deep Visibility into Application Performance
>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>> Monitor end-to-end web transactions and take corrective actions now
>> Troubleshoot faster and improve end-user experience. Signup Now!
>> http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
>> ___
>> Geoserver-devel mailing list
>> Geoserver-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>
>>
>
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Proposing some more cleanup in the community module section

[Justin Deoliveira]

istyler was a prototype that never got up and running. Pretty safe it can
be killed.

On Mon, Feb 1, 2016 at 2:05 AM Andrea Aime 
wrote:

> On Mon, Feb 1, 2016 at 9:55 AM, Simone Giannecchini <
> simone.giannecch...@geo-solutions.it> wrote:
>
>> adding to your list:
>>
>> - geoserver-sync ??
>>
>
> Right, geoserver-sync was in my first version of the mail, and I also
> added jjjtaylor to the cc list because of that,
> but wasn't sure, and I then removed it.
> Still believe it's a good candidate, it has not been touched for over 2
> years.
>
>
>> - geoxacml ??
>>
>
> Afaik this one is dead too (as in, not functional at all). Christian, can
> you confirm?
>
>
>> - istyler ??
>> - FTP ??
>>
>
> Right, not sure anyone is using these.
>
> I'd be for dropping all of the above if we don't hear complaints.
>
> Cheers
> Andrea
>
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V 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.
>
> ---
>
> --
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
> ___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Demoting GeoSearch to community module?

[Justin Deoliveira]

Yeah, I can’t imagine the structure used by the geosearch extension is even
valid anymore according to google standards. I would axe it. If someone
complains we can always dig it out of version control.

On Thu, Jan 21, 2016 at 4:00 PM Andrea Aime 
wrote:

> Hi,
> we had a bit of discussion here at the code sprint and it seems nobody has
> used
> GeoSearch in ages, and/or nobody managed to make Google scrape the KML it
> generates anyways.
> And nobody really remembers how it works to start with.
>
> It's an extension module, shall we demote it to community?
> Drop the axe and just remove it?
>
> Cheers
> Andrea
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V 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.
>
> ---
>
> --
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
> ___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] a bit stuck on 2.9-M0 release

[Justin Deoliveira]

Hey Jody.

Thanks for the revision info. I checked out and built everything locally
and I was able to build a working mac installer without issue. No jetty
problems… So not sure, perhaps the installer relies on something specific
to my setup, not sure. Let’s debug your setup.

On Tue, Jan 19, 2016 at 2:54 PM Jody Garnett  wrote:

> Justin it looks like 2.9-M0 was not tagged by ares release script (sigh).
>
> Here are the revisions used for the release:
>
> *version = 2.9-M0*
> *git revision = 577f89dfd3c7302dae1b84f0e95e145322f94ed6*
> *git branch = 577f89dfd3c7302dae1b84f0e95e145322f94ed6*
> *build date = 17-Dec-2015 08:01*
> *geotools version = 15-M0*
> *geotools revision = fe28f403c9008d39a70b8d5f1b12340b46b875c7*
> *geowebcache version = 1.9-M0*
> *geowebcache revision = 8d9a56855f56f25e73eb3866c275dc49dd793335/8d9a5*
> *hudson build = -1*
>
> *geotools=15-M0*
> *geowebcache=1.9-M0*
>
>
>
> On Thu, 24 Dec 2015 at 09:58 Jody Garnett  wrote:
>
>> Okay got a lead ... the bin download has the same list of jars (two ant
>> jars etc...)
>>
>> I moved the JAI jars (jai_codec-1.1.3.jar,
>> jai_core-1.1.3.jar,jai_imageio-1.1.jar) from webapps/geoserver/WEB-INF/libs
>> to the jetty libs folder - and now the application can start up (and
>> appears to function).
>>
>> The logs of this startup are here
>> https://www.dropbox.com/s/687mevu083w1fpd/2.9-M0-bin-hack-logs.txt?dl=0
>>
>> I am going to assume that we need to mess with the new jetty
>> configuration / classpath (rather than move jars around).
>>
>> For reference the jetty lib folder now contains:
>>
>> ant-1.6.5.jar
>>> ant-1.8.4.jar
>>> ant-launcher-1.8.4.jar
>>> commons-el-1.0.jar
>>> commons-logging-1.1.1.jar
>>>
>>
>>> *jai_codec-1.1.3.jar*
>>> *jai_core-1.1.3.jar*
>>> *jai_imageio-1.1.jar*
>>
>> jasper-compiler-5.5.15.jar
>>> jasper-compiler-jdt-5.5.15.jar
>>> jasper-runtime-5.5.15.jar
>>> javax.servlet-api-3.1.0.jar
>>> jetty-deploy-9.2.13.v20150730.jar
>>> jetty-http-9.2.13.v20150730.jar
>>> jetty-io-9.2.13.v20150730.jar
>>> jetty-schemas-3.1.M0.jar
>>> jetty-security-9.2.13.v20150730.jar
>>> jetty-server-9.2.13.v20150730.jar
>>> jetty-servlet-9.2.13.v20150730.jar
>>> jetty-util-9.2.13.v20150730.jar
>>> jetty-webapp-9.2.13.v20150730.jar
>>> jetty-xml-9.2.13.v20150730.jar
>>> jsp-api-2.0.jar
>>> log4j-1.2.14.jar
>>
>>
>>
>>
>>
>> --
>> Jody Garnett
>>
>> On 24 December 2015 at 09:00, Andrea Aime 
>> wrote:
>>
>>> On Thu, Dec 24, 2015 at 5:57 PM, Jody Garnett 
>>> wrote:
>>>
 I have not experimented yet, was going to compare to prior releases.

>>>
>>> Hum... not sure you have much to compare to, M0 is getting released also
>>> because
>>> Jetty was upgraded, and thus not the same as in the previous releases,
>>> no? :-)
>>>
>>> Cheers
>>> Andrea
>>>
>>> --
>>> ==
>>> GeoServer Professional Services from the experts! Visit
>>> http://goo.gl/it488V for more information.
>>> ==
>>>
>>> *Geosolutions' Winter Holidays from 24/12 to 6/1*
>>>
>>> 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 

Re: [Geoserver-devel] removing some community modules?

[Justin Deoliveira]

- python has been superseded by the script module
- dbconfig has been superseded by jdbcconkfig

I would say both of these can go.

The python module still has some docs in the user guide… we should kill
those as well.

On Mon, Jan 18, 2016 at 4:48 PM Jody Garnett  wrote:

> These modules do not have profiles in the build, anyone mind if I remove
> them?
>
> - w3ds - not updated to latest geotools, not in build profile
> - scriptlet - prototype javascript integration replaced by geoscript
> integration
>
> The following community modules are also inactive:
>
> - dbconfig
> - wfs notification
> - python
>
> Please reply to this thread if you know more, or want to keep any of the
> above modules.
> --
> Jody Garnett
>
> --
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
> ___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] GeoTools / GeoServer Meeting 2015-12-01

[Justin Deoliveira]

On Tue, Dec 1, 2015 at 2:37 PM Ben Caradoc-Davies  wrote:

> GeoTools / GeoServer Meeting 2015-12-01
> ===
>
> Attending
> -
>
> Ben Caradoc-Davies
> Kevin Smith
> Jody Garnett
> Jukka Rahkonen
> Ian Turton
> Niels Charlier
> Torben Barsballe
> Andrea Aime
>
> Agenda
> --
>
> - PSC changes
> - uDig problems with Boundless Maven repository
> - Resource API migration
> - Jetty / Spring version upgrade
> - Java 8 change
>
> Actions
> ---
>
> - Jody: update GeoServer PSC list [DONE]
> - Ben: email Ian and Brad to ask if interested in joining PSC
> - Ben: merge ResourceStore changes
> - Ben: switch GeoServer and GeoTools master to Java 8
> - Kevin: switch GeoWebcache master to Java 8
> - Ian Turton to release GeoServer this month
> - Jody: release milestone
>
> Actions from last meeting
> -
>
> - Jody: merge GeoTools PR #1030 and backport to 14.x for 14.1/2.8.1
> [DEFERRED see #1055]
> - Jody: merge GeoTools PR #1048 for 14.x for 14.1 release [DONE]
> - Ben: release 14.1/2.8.1 [DONE]
> - Alessio: release 2.7.4
> - Ben: simplify Jira workflow for GeoTools and GeoServer [DONE]
> - Jody: call for nominations for PSC on mailing list
> - Jody: nominate Kevin Smith for PSC on mailing list [DONE]
> - Kevin: GeoTools / GeoServer - change from snapshot to main (to prevent
> HTTP 409). Kevin will prepare pull request [DONE]
>
> PSC changes
> ---
>
> - Kevin Smith joins the GeoServer PSC
> - Phil Scadden steps down from the GeoServer PSC
> - Ask for user representative?
> - Look for individuals who has been active on the user mailing list?
>a) Ian Turton
>b) Brad Hards
>
> - Action [Done] Update
>
> https://github.com/geoserver/geoserver/blob/master/doc/en/developer/source/policies/psc.rst
>
> - Action: email Ian and Brad to ask for interest
>
> uDig problems with Boundless Maven repository
> -
>
> - Should be solved
>- Original repo failed in september
>- Http redirect and http proxy pointing to artifactoryonline did not
> work out as replacement
>- Now repo.boundlessgeo.com/main DNS changed to directly reference
> artifactory online
> - uDig repo may not yet have been restored?
>
> ResourceStore API migration
> ---
>
> Here is the wiki page:
> *
>
> https://github.com/geoserver/geoserver/wiki/Cleaning%20up%20File%20References
>
> https://github.com/geoserver/geoserver/pull/1346
> https://github.com/GeoWebCache/geowebcache/pull/354
>
> - This is not a new proposal, it is the "second half" of the proposal
> https://github.com/geoserver/geoserver/wiki/GSIP-106
> https://github.com/geoserver/geoserver/wiki/ResourceStore-API-Examples
>
> - Large pull request exceeds GitHub limits, last 57 files show no
> changes (so look at individual commits!)
> - GitHub support apologise, plan to implement a warning notice
>
> Niels:
> - This can use extra testing during review/merge (request a couple of
> hours testing before merge)
> - Or apply to master and ask for nightly-build testing
> - Include in a milestone? Yes.
>
> Discussion:
> - Jody: Consider testing this with new version of spring / jetty?
> - Ian: how to tell what caused failure?
> - Niels: no more pending changes - this is good to go
> - Resolution of base directory access question? Via
> GeoServerResourceLoader.
>
> Q: try-with-resource syntax? Could not fix for rest module due to
> pom.xml setting. A: fix it!
> Q: Ben can you review and merge? A: yes!
>
> Jetty / Spring version upgrade
> --
>
> Spring appears low risk:
> - applied to master, low-risk to backport.
>
> Jetty requires testing:
> - Boundless uses Jetty 7.6.13.v20130916 (we jumping to 9.2 so it does
> not help)
> - Jody will volunteer to make a milestone release. Send to user list.
> - After testing of milestone, we can make decision about backport
>
> Q: Do we know Justin's timeframe? Ask on mailing list ...
>
> No time frame. I’ve already done the back port on a branch and I am
working from that for the project. I am happy to continue to do that if the
PSC feels the upgrade is too risky.

I can also potentially put time toward some of the things Andrea suggested
to mitigate risk. If the PSC can decide what the acceptance criteria I can
let you know what I can take on.


> Java 8
> --
>
> Ben++!!!
> Volunteers to switch the codebase to java 8.
>
> Action:[Kevin] Confirm ares has OpenJDK and Oracle Java 8?
>
> Warning: build times with java 8 are slower ...
>
> Release Schedule
> 
>
> - https://github.com/geoserver/geoserver/wiki/Release-Schedule
>
> Ian volunteers for 2015-12-18 GeoTools 13.5 / GeoServer 2.7.5.
>
> Pull requests
> -
>
> https://github.com/geotools/geotools/pull/1051
> - waiting on feedback :)
>
> https://github.com/geotools/geotools/pull/1057
> - having some trouble communicating design with ahuarte47, fixes in
> isolation address the specific 

Re: [Geoserver-devel] GeoTools / GeoServer Meeting 2015-12-01

[Justin Deoliveira]

On Tue, Dec 1, 2015 at 3:20 PM Jody Garnett <jody.garn...@gmail.com> wrote:

> I was going to punt out a milestone release of master and test on Windows
> / OSX. Based on that I think we are happy to backport.
>
> Cool.


> Acceptance criteria mostly focused on OS X and windows installers
> continuing to function. I am a little gun shy based on recent log4j / jetty
> conflict in ares.
>
> Fair enough. Only logging issue I can remember was having to upgrade the
version of slf4j and the slf4j log4j adapter.


> Do you have any feedback on updating windows / OS X installers to Java 8?
>

Nothing specific. The mac installer uses a tool called appbundler to bundle
a jre which is the recommended way to ship java apps for osx.  As far as I
know it should work without any changes. If it doesn’t when the time comes
I can take a look.

On Tue, Dec 1, 2015 at 2:17 PM Justin Deoliveira <jdeol...@gmail.com> wrote:
>
>> On Tue, Dec 1, 2015 at 2:37 PM Ben Caradoc-Davies <b...@transient.nz>
>> wrote:
>>
>>> GeoTools / GeoServer Meeting 2015-12-01
>>> ===
>>>
>>> Attending
>>> -
>>>
>>> Ben Caradoc-Davies
>>> Kevin Smith
>>> Jody Garnett
>>> Jukka Rahkonen
>>> Ian Turton
>>> Niels Charlier
>>> Torben Barsballe
>>> Andrea Aime
>>>
>>> Agenda
>>> --
>>>
>>> - PSC changes
>>> - uDig problems with Boundless Maven repository
>>> - Resource API migration
>>> - Jetty / Spring version upgrade
>>> - Java 8 change
>>>
>>> Actions
>>> ---
>>>
>>> - Jody: update GeoServer PSC list [DONE]
>>> - Ben: email Ian and Brad to ask if interested in joining PSC
>>> - Ben: merge ResourceStore changes
>>> - Ben: switch GeoServer and GeoTools master to Java 8
>>> - Kevin: switch GeoWebcache master to Java 8
>>> - Ian Turton to release GeoServer this month
>>> - Jody: release milestone
>>>
>>> Actions from last meeting
>>> -
>>>
>>> - Jody: merge GeoTools PR #1030 and backport to 14.x for 14.1/2.8.1
>>> [DEFERRED see #1055]
>>> - Jody: merge GeoTools PR #1048 for 14.x for 14.1 release [DONE]
>>> - Ben: release 14.1/2.8.1 [DONE]
>>> - Alessio: release 2.7.4
>>> - Ben: simplify Jira workflow for GeoTools and GeoServer [DONE]
>>> - Jody: call for nominations for PSC on mailing list
>>> - Jody: nominate Kevin Smith for PSC on mailing list [DONE]
>>> - Kevin: GeoTools / GeoServer - change from snapshot to main (to prevent
>>> HTTP 409). Kevin will prepare pull request [DONE]
>>>
>>> PSC changes
>>> ---
>>>
>>> - Kevin Smith joins the GeoServer PSC
>>> - Phil Scadden steps down from the GeoServer PSC
>>> - Ask for user representative?
>>> - Look for individuals who has been active on the user mailing list?
>>>a) Ian Turton
>>>b) Brad Hards
>>>
>>> - Action [Done] Update
>>>
>>> https://github.com/geoserver/geoserver/blob/master/doc/en/developer/source/policies/psc.rst
>>>
>>> - Action: email Ian and Brad to ask for interest
>>>
>>> uDig problems with Boundless Maven repository
>>> -
>>>
>>> - Should be solved
>>>- Original repo failed in september
>>>- Http redirect and http proxy pointing to artifactoryonline did not
>>> work out as replacement
>>>- Now repo.boundlessgeo.com/main DNS changed to directly reference
>>> artifactory online
>>> - uDig repo may not yet have been restored?
>>>
>>> ResourceStore API migration
>>> ---
>>>
>>> Here is the wiki page:
>>> *
>>>
>>> https://github.com/geoserver/geoserver/wiki/Cleaning%20up%20File%20References
>>>
>>> https://github.com/geoserver/geoserver/pull/1346
>>> https://github.com/GeoWebCache/geowebcache/pull/354
>>>
>>> - This is not a new proposal, it is the "second half" of the proposal
>>> https://github.com/geoserver/geoserver/wiki/GSIP-106
>>> https://github.com/geoserver/geoserver/wiki/ResourceStore-API-Examples
>>>
>>> - Large pull request exceeds GitHub limits, last 57 files show no
>>> changes (so look at individual commits!)
>>> - GitHub support apologise, plan to implement a warning notice
>>>
>>&

Re: [Geoserver-devel] Backporting spring and jetty changes

[Justin Deoliveira]

Fair enough. I will say that I have to do the back port regardless for a
project but I can easily work from a branch in my own fork for now if folks
decide it’s not worth the risk.

As for mitigating the risk, your suggestions all sound good. Regarding
updating a demo server the only people I know that run a stable GeoServer
demo are Boundless and GeoSolutions. So I’ll let those devs comment on if
they want to do an upgrade. I can cut a 2.8.x build with the library
upgrades or they can grab a nightly from master. Just let me know.

As for running benchmarks is there a test suite that is readily available
and easy to set up? Depending on how much work is involved there I can
volunteer some time to put to that.

As for a milestone release from master I can also put some time toward that
as long as it’s something I can bust off in a few hours time frame. If
there is going to be more ceremony around it not sure how much time I can
devote to it at the moment.

On Fri, Nov 27, 2015 at 2:46 AM Andrea Aime <andrea.a...@geo-solutions.it>
wrote:

> Hi Justin,
> this one had me thinking a while :-)
>
> So, there are two separate things. The first one is the Spring upgrade.
> It's an upgrade between
> two minor versions, had a single commit, basically just the version number
> change in the pom files, worked fine.
> The Spring integration is exercised by our tests and by the CITE tests,
> all of them seem to be working fine.
> An upgrade of the library that wires everything is still risky, but given
> the above I'm not too concerned... let's make that a +0?
>
> I believe the Jetty upgrade is more contentious, more reward and more risk.
> The Jetty we are shipping with on 2.8.x is a bit of an horror, old,
> inefficient, with known security risks, so an
> upgrade is very much welcomed.
> Testing wise however we are coming out pretty light though. We had the
> CITE tests running on master for a few
> days, and I believe some people tested it interactively... but the stable
> series is meant for production, so I believe
> we need more than that.
> And then we have the installers: how many people have tried the windows
> and OSX installer with the new Jetty and can attest they are working?
> Possibly a number <= 1, assuming Justin has had the time to check both
> when making the Jetty upgrade :-p
>
> So... from this point of view I'd be -1 on the Jetty upgrade, but at the
> same time... it would be so good...
> so what can be done to mitigate those risks?
> Here is a few of ideas, hopefully others will add more/better ones:
> * Have a well known demo instance of GeoServer somewhere use the new bin
> package and see how it stands the load
> * We could run some of the benchmarking exercises on top of it
> * To have people use the installers, maybe cut a milestone release out of
> trunk? We have a few new features
>already in there to sweeten the pot and make it more interesting for
> people to kick its tires
>
> What do you think?
>
> Cheers
> Andrea
>
>
>
> On Thu, Nov 26, 2015 at 6:25 PM, Justin Deoliveira <jdeol...@gmail.com>
> wrote:
>
>> Hey folks, I wanted to get a feel for how devs would feel about back
>> porting the recent jetty and spring upgrades to the 2.8.x branch? I’ve been
>> working with them on master without any issues, not sure if anyone else has
>> run into any hitches though.
>>
>> If people do think this is a safe back port is now (with a 2.8 release
>> pretty fresh out the door) a good time?
>>
>> Thanks!
>>
>> -Justin
>>
>>
>> --
>> Go from Idea to Many App Stores Faster with Intel(R) XDK
>> Give your users amazing mobile app experiences with Intel(R) XDK.
>> Use one codebase in this all-in-one HTML5 development environment.
>> Design, debug & build mobile apps & 2D/3D high-impact games for multiple
>> OSs.
>> http://pubads.g.doubleclick.net/gampad/clk?id=254741551=/4140
>> ___
>> Geoserver-devel mailing list
>> Geoserver-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>
>>
>
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V 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