Re: [Geoserver-devel] spring 4 upgrade

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

Re: [Geoserver-devel] spring 4 upgrade

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

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

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: > Kev

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

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 wo

Re: [Geoserver-devel] Travis builds not helping pull requests anymore

> The other two are clearer, we depend on some old jars that are no more > available in central and that are now > not available on the boundless repo either (they were available on the old > repo.opengeo.org though). > > Is that stuff that can added back by a manual install? > Yes it is. Limited

[Geoserver-devel] Travis builds not helping pull requests anymore

Hi, most of the pull request builds are failing due to errors like the following: [ERROR] Failed to execute goal on project gs-libjpeg-turbo: Could not resolve dependencies for project org.geoserver.extension:gs-libjpeg-turbo:jar:2.9-SNAPSHOT: Failed to collect dependencies at it.geosolutions.imag

Re: [Geoserver-devel] spring 4 upgrade

+1 to stick with Spring 4 /login and /logout as it is less crufty, more consistent with modern Spring (e.g. Spring Boot), as Chris noted there is an easy upgrade path for users, and we will never get a better time to upgrade. Kind regards, Ben. On 15/03/16 03:35, Justin Deoliveira wrote: > Gre

[Geoserver-devel] [JIRA] (GEOS-7459) Securing an app-schema data store may result in ClassCastException being thrown

Title: Message Title Stefano Costa created

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

Can we review/vote on the proposal as it stands (it says targeting 2.10). If the work is delayed due to 2.9 release slip then it can start in a feature branch (or as a community module if you think that will work - it should probably work). -- Jody Garnett On 14 March 2016 at 09:46, Andrea Aime

Re: [Geoserver-devel] Freeze for 2.9

Forgive my enthusiasm - I am rather stoked that the initial "getting it to work" has only taken a week, rather than several weeks. I had thought we would be wrestling much longer with secruity and security-cas ... Updating the wiki now with test plan (emphasis rest-api, security, security ldap, se

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

On Mon, Mar 14, 2016 at 4:29 PM, Jody Garnett wrote: > I had not considered a community module - since a proposal (and not a > community module) was used when a REST API was added for resources I > assumed the same would be needed when adding a GUI. > I see... so I'm confused, you think of addin

Re: [Geoserver-devel] Freeze for 2.9

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 Just

Re: [Geoserver-devel] Freeze for 2.9

On Mon, Mar 14, 2016 at 4:22 PM, 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 t

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

I had not considered a community module - since a proposal (and not a community module) was used when a REST API was added for resources I assumed the same would be needed when adding a GUI. -- Jody Garnett On 14 March 2016 at 05:06, Andrea Aime wrote: > Hi Niels, > first off, can you explain w

Re: [Geoserver-devel] Freeze for 2.9

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-bet

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

Think we all got distracted by bigger release scheduling questions. Quick feedback: do we need a download button - or could we make the file links clickable? Any update on a wicketstuff compatible with spring 4? -- Jody Garnett On 14 March 2016 at 04:57, Niels Charlier wrote: > So... is

Re: [Geoserver-devel] spring 4 upgrade

I also vote we go with this approach, we will need to remember to add a note to the release notes. -- Jody Garnett On 14 March 2016 at 08:35, Justin Deoliveira wrote: > 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 t

Re: [Geoserver-devel] Freeze for 2.9

Ciao Justin, for 2.9 we are already piling up the upgrade to wicket (which is causing problems, see latest emails) with the upgrade to spring 2.4 which came in at the very last minute. I guess we have allowed enough major changes wrt adding even more. All the people I talk to demand more stability

Re: [Geoserver-devel] spring 4 upgrade

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 wrote: > Justin, > > > > For us it is a simple change to a wrapping HTML page. It doesn’t make > sense for us to

Re: [Geoserver-devel] spring 4 upgrade

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 proce

Re: [Geoserver-devel] Freeze for 2.9

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-s

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, 201

Re: [Geoserver-devel] spring 4 upgrade

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 wel

Re: [Geoserver-devel] Semi-backwards incompatible change: disable by default geometry simplification in postgis?=

+1 until some one finds the time to update the simplification query. Ian On 14 March 2016 at 08:44, Simone Giannecchini < simone.giannecch...@geo-solutions.it> wrote: > +0 > Regards, > Simone Giannecchini > == > GeoServer Professional Services from the experts! > Visit http://goo.gl/it488V for m

[Geoserver-devel] Freeze for 2.9

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 i

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

That is something you should discuss with Jody, it was his request to me to do it this way. Regards Niels On 14-03-16 12:06, Andrea Aime wrote: Hi Niels, first off, can you explain why we need a formal proposal to start with? It seems to me a GUI for resources can start as a community module a

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

Hi Niels, first off, can you explain why we need a formal proposal to start with? It seems to me a GUI for resources can start as a community module and grow its way up to supported land. Cheers Andrea On Mon, Mar 14, 2016 at 11:57 AM, Niels Charlier wrote: > So... is anyone going to vote

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

Hi Ben, I'll open up a new thread about this. 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) I

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

So... is anyone going to vote for this proposal? Regards Niels On 12-03-16 21:24, Justin Deoliveira wrote: 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

[Geoserver-devel] [JIRA] (GEOS-7458) Java process segfault in LCMS library

Title: Message Title Landry Breuil created

[Geoserver-devel] [JIRA] (GEOS-7457) Bad System.out.println logging usage

Title: Message Title Landry Breuil created

Re: [Geoserver-devel] Semi-backwards incompatible change: disable by default geometry simplification in postgis?=

+0 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

[Geoserver-devel] Semi-backwards incompatible change: disable by default geometry simplification in postgis?=

Hi, given that people keep on complaining that polygons disappear when fairly zoomed out, using a postgis source, I was wondering if we should just disable the postgis in database simplification flag by default, still allowing people to enable it if they want to? Cheers Andrea -- == GeoServer P