Re: [Geoserver-devel] W3DS Implementation up and running

[Justin Deoliveira]

Hi Nuno,

No problem about the misformatting, it is a very common thing for people
contributing initial patches. The new patch looks much nicer, thanks!

So, its looking good for the most part. Although it looks like 3d is only
respected if the 2d hint is specified to be false. I think it should be
respected if the 2d hint is false, or the 2d hint is not specified at all.

Also one thing is that we need to deprecate the old
SQLDialect.encodeColumnName method, and probably have the implementation
call through to the new one.

As for the test i think it looks good, although with the behavior i
mentioned above about interpreting the 2d hint it should no longer be
necessary to override any of hte test methods in Postgis3D test.

-Justin

On Thu, May 3, 2012 at 11:15 AM, Nuno Miguel Carvalho Oliveira <
nmco51...@gmail.com> wrote:

> Hi Justin,
>
> I'm really sorry about the patch i haven't seen the formatting trick
> (sorry for the waste of time).
> I send in annex two patchs one who makes the changes in the existing
> classes and another to add the PostGIS 3D tests.
>
> I hope i did it well this time.
>
> Regards,
>
> Nuno Oliveira
>
>
>
>
>
> 2012/5/3 Justin Deoliveira 
>
>> Hi Nuno,
>>
>> The changes make sense, unfortunately the patch still has issues. The
>> patch contains largely formatting changes. Looks like spaces were converted
>> to tabs at some point. This unfortunately makes it nearly impossible to
>> figure out what actually changed in that class. Seems to be mostly
>> the PostGISDialect class, but also the test classes contain misformatting
>> in terms of tabs vs spaces.
>>
>> Not sure what IDE you are using but if you are using eclipse there are
>> existing formatting templates that will help with this. See this for more
>> details.
>>
>>   http://docs.geotools.org/latest/developer/conventions/code/style.html
>>
>> Again, to reiterate, for any patches that are proposed it is imperative
>> that they only contain relevant changes, and no formatting changes.
>>
>> -Justin
>>
>>
>> On Wed, May 2, 2012 at 8:22 AM, Nuno Miguel Carvalho Oliveira <
>> nmco51...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> (Sorry for the late reply, i had a very very busy week).
>>>
>>> First, thank you for your very complete answer.
>>> I create a new patch based on your advices (in annex).
>>> Basically to read 3D coordinates from a PostGIS data
>>> base we need to put a hint in the query:
>>>
>>>   Hints hints = query.getHints();
>>>   hints.put(Hints.FEATURE_2D, Boolean.FALSE);
>>>   query.setHints(hints);
>>>
>>> This hint will remove 'ST_Force_2D' from the final querry
>>> and set the encode to 'ST_AsEWKB' instead of 'ST_AsBinary'.
>>>
>>> I run the tests and all works fine (PostGIS3DTest).
>>>
>>> To resume what i have changed:
>>>
>>> - SQLDialect.java and PostGISDialect.java: I extend the
>>>   'encodeGeometryColumn' function to take also the 'Hints'
>>>   as a parameter.
>>> - JDBCDataStore.java: I give the 'Hints' as a parameter
>>>   to the 'encodeGeometryColumn' function.
>>> - PostGIS3DTest and PostGIS3DTestSetup: I add 3D tests
>>>   to PostGIS.
>>>
>>>
>>> Any suggestions are very welcome.
>>>
>>> Regards,
>>>
>>> Nuno Oliveira
>>>
>>>
>>> 2012/4/21 Andrea Aime 
>>>
 On Thu, Apr 19, 2012 at 7:01 AM, Nuno Miguel Carvalho Oliveira <
 nmco51...@gmail.com> wrote:

> Hi,
>
> Follows in anexe two patchs, one to integrate W3DS as a community
> module in GeoServer and another to GeoTools who  permits the acess of 3D
> data from a PostGIS data base. Related to the acess of 3D data in GeoTools
> maybe it exists a better way to do this, any idea is welcome.
>
>
 Hi,
 let's start discussing the Geotools patch, since it's really short.
 The patch is almost correct, but it's mis-using the hints somehow.

 Hints are used in the query as a way to tell the store that we'd
 like the returned objects to have some particular property, such as
 being
 built with a particular geometry factory, or being flat (2D).
 The geometry column user data is instead used to carry some extra info
 that describes it, such as the fact the column is a "geography" instead
 of a
 "geometry".

 Query hints are created per request and can vary over time, for example
 WMS will always ask for 2D geometries, whilst W3DS or WFS won't.
 Geometry descriptor attributes instead are structural, once set they
 describe
 something about the geometry column "forever".

 As such you should not mix them, otherwise one request can force the
 geometry to be 2d by attaching the hint and the next request looking for
 3d data won't get it (because the hint is already in place).
 To do what you want is better to extend the encodeGeometryColumn in
 SQLDialect  to take also the Hints as a parameter: it is an API break
 that
 I believe we can take on trunk (Justin, thoughts?).

 The other thing t

[Geoserver-devel] [jira] (GEOS-5089) Document admin access mode

[Justin Deoliveira (JIRA)]

Justin Deoliveira created GEOS-5089:
---

 Summary: Document admin access mode
 Key: GEOS-5089
 URL: https://jira.codehaus.org/browse/GEOS-5089
 Project: GeoServer
  Issue Type: Task
  Components: Security
Reporter: Justin Deoliveira
Assignee: Justin Deoliveira


Users upgrading to 2.2 will run into problem if they have opened up the rest 
api to be accessed anonymously or by the non-admin user. Now with the admin 
access mode the default is to provide admin privileges only to role 
administrator. The upshot is that the user will no longer see any workspaces 
because they don't have admin privileges on them any longer.

This should be clearly documented for those upgrading to 2.2.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] wms.xml, wfs.xml, wcs.xml wps.xml files get cleared of content making services unavailable

[Moreau, Christopher]

Thanks for the response Justin. I work w. Robert.  We have been attempting to 
do just what you have recommended, unfortunately, without success.  So it's 
hard for us to know if  newer version has addressed the issue. We've done 
testing with a trunk release from March 12, 2012 and with 2.2 beta 1, but bugs 
in their rest interfaces made those version a non-option for us.  We also 
looked through Jira.

We are posting to see if anyone else has experienced this and has either found 
a way to reproduce it or found  a way to prevent it.  We'll continue to try to 
reliably reproduce.

Respectfully,

Chris Moreau
Manager, Software Engineering
General Dynamics Information Technology
8989 Rio San Diego Dr., Suite 330
San Diego, CA 92108
W: (619) 684-7909
M: (619) 379-9939

From: Justin Deoliveira [mailto:jdeol...@opengeo.org]
Sent: Thursday, May 03, 2012 8:44 AM
To: Brister, Robert L
Cc: geoserver-devel@lists.sourceforge.net; Moreau, Christopher
Subject: Re: [Geoserver-devel] wms.xml, wfs.xml, wcs.xml wps.xml files get 
cleared of content making services unavailable

Hi Robert,

I don't know of any outstanding jira ticket specifically for this issue. You 
could try a newer version and see if the problem persists.

All in all your best bet is going to be to try as best you can to reliably 
reproduce the problem and then find a way to have a developer reproduce the 
problem. Without that I am not sure what can be done.

Perhaps you can try to set up a watcher script that notifies when the files are 
flushed away. And perhaps in parallel to that turn on request level logging in 
your servlet container and try to compare timestamps to see indeed what is 
going on and perhaps what lead to it.

-Justin
On Wed, May 2, 2012 at 2:50 PM, Brister, Robert L 
mailto:robert.bris...@gdit.com>> wrote:
Issue:
We have an issue where the wms.xml, wfs.xml, wcs.xml and wps.xml files in 
GeoServer from time to time get cleared of content, thus resulting in no 
services being available.

Environment:
   We have 2 environments. Both exhibit the issue.

1)  Environment 1

a.   GeoServer version 2.1.x

b.  Running on RHEL 5.7

c.   JBoss 5.1

d.  Clustered configuration

   i.   
   4 GeoServer Instances clustered sharing global file external data directory

 ii.
  F5 Load balancer in front of the GeoServers.

2)  Environment 2

a.   GeoServer version 2.1.x

b.  Running on RHEL 5.7

c.   JBoss 5.1

d.  Clustered configuration

   i.   
   2 GeoServers Clustered, sharing global file external data directory

 ii.
  F5 Load balancer in front of the GeoServers.
Theory:
We 'think' this may be triggered by a rest reload command.
We do a reset reload command because we use the rest interface to create new 
layers.  The call is made via one of the clustered GeoServers, and a reload of 
the other GeoServers in the cluster is required in order for them to become 
aware of the newly created layers.
It has been our observation that a back-to-back reload command often precedes 
the issue occurring.

Request:
I attempted to see if this issue has been reported as bug in the Jira system, 
but did not find a report that I thought was a match.
Has anyone else experienced this issue?
Is there an existing bug report for this issue?
Has this issue be addressing in a newer release?
Any ideas?

Thanks in advance.

Respectfully,

Chris Moreau



Robert L Brister
Principal Software Engineer
General Dynamics Information Technology
FNMOC, Monterey, CA
Building 704, Rm 235
Ph: 831-656-5056
Cell: 408-569-5954
robert.bris...@gdit.com

UNCLASSIFIED//FOR OFFICIAL USE ONLY//


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel



--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malw

Re: [Geoserver-devel] More on name conflict resolution (in REST API)

[David Winslow]

Yes, I have expanded a bit from the original topic.  I already have made
some improvements to the way temporary files are handled in the data upload
process that don't change existing APIs so perhaps we can put off these
other topics for a later release - I have a fair bit of work cut out for me
translating my external test scripts into unit tests, and reviewing the
file handling in the coverage upload stuff as well.  My main focus here is
GeoNode, where stores other than Shapefile and PostGIS are vanishingly rare
so I guess schema mismatching issues won't come up much.

With respect to how we could better handle schema adaptation, I agree with
you that stores should be responsible for knowing what they can encode.  I
was suggesting FeatureAdjuster as an alternative to a Map for representing
an adjusted schema, not as a static repository of all schema-adjusting
knowledge.  I think if we want to improve the error handling on appending
through the REST API it will be important to decouple schema adjustment
from table creation, but it will probably be useful to have a convenience
method like the createSchema(FeatureCollection col, Hints hints) you
suggest.

Anyway, I'll step out of the deep end for now and get to work on bringing
my existing patch for http://jira.codehaus.org/browse/GEOS-5056 up to a
better level of testing/documentation.

--
David Winslow
OpenGeo - http://opengeo.org/

On Tue, May 1, 2012 at 3:21 PM, Andrea Aime wrote:

> On Tue, May 1, 2012 at 3:36 PM, David Winslow wrote:
>
>> Creating a schema is actually not that big a problem: assuming that all
>> datastores create tables (or whatever) that can *accept* features
>> conforming to the passed-in schema, the REST API importer can handle the
>> importing without worrying too much about the munging that's going on
>> "behind the scenes."  That's how things work today, and it seems to
>> generally work fine.
>
>
> Err.. which is exactly the problem. Try importing a shapefile with
> lowercase attributes in Oracle, if you don't uppercase them
> manually during the copy you'll get a table with all NULL values, the same
> will happen with shapefiles afaik (try pushing random
> GML into a shapefile and you should see that).
> You need some information about how the attribute names have been
> transformed to do something sensible.
>
> I've attached to this mail two import scripts I use to load shapefiles
> into Oracle and SDE, you can see that both
> are using some soft knowledge of how that particular store adds data in
> order to actually do a successfull import.
> Both are actually lacking and not really dealing with the whole set of
> issues (they are just throw-aways anyways).
>
> Imho it would be much better if it was the store itself to handle the
> problem to start with, instead of trying with
> some external heuristic set that only handles some of the issues we know
> we have today.
>
> I mean.. using createSchema(...) you don't even know if the name of the
> feature type has been preserved, or not
> (in general, at least). In Oracle it hasn't for example, it has been
> turned uppercase, in SDE you get a prefix
> in front of it.
>
> A way to get these feature inside the stores in this release is to have
> selected stores implement the
> createSchema(FeatureCollection, Hints) method, and access is reflectively
> if available, whilst on the
> new trunk it could be called directly.
>
> Or you can go on with the FeatureAdjuster idea... but imho it's only going
> to be a limited hack
>
> That said... maybe I'm talking about a different problem? The thread
> started talking about conflicts
> with existing feature types, which is not the same thing as creating a new
> one and having to deal
> with how the feature type has been altered by the store.
>
> Cheers
> Andrea
>
> --
> ---
> Ing. Andrea Aime
> GeoSolutions S.A.S.
> Tech lead
>
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
>
> phone: +39 0584 962313
> fax:  +39 0584 962313
> mob:+39 339 8844549
>
> http://www.geo-solutions.it
> http://geo-solutions.blogspot.com/
> http://www.youtube.com/user/GeoSolutionsIT
> http://www.linkedin.com/in/andreaaime
> http://twitter.com/geowolf
>
> ---
>
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] GSIP 69 - Catalog scalability enhancements - proof of concept

[Andrea Aime]

On Thu, May 3, 2012 at 6:00 PM, Gabriel Roldan  wrote:

> On Sat, Apr 28, 2012 at 11:30 AM, Andrea Aime
>  wrote:
> > Moving forward with the discussion about the code being "proof of
> concept".
> >
> > By "proof of concept" I don't mean that the code is bad, I mean that
> it's a
> > stage
> > where it proofs the concept but it's not ready to be integrated in a code
> > based that was meant to become stable soon, simply because it's last
> minute
> > (last minute changes are rarely good) and imcomplete.
> Well, the "soon to be stable" 2.2 branch is out of the question.
> Question is whether we'll allow progress to occur in the "soon to be
> trunk" 2.3 branch, or (surprisingly) everything needs to be nailed
> down to the minimal detail to allow new development to happen on
> trunk.
>

My feedback was still based on the idea that you wanted to commit the work
on 2.2.x
I saw Justin say it would not have happened, but it I did not see you say
the
same, and you're the proponent of the GSIP, so I (wrongly) assumed you
wanted to
go on and still commit on 2.2.x


> > So in the end the same amount of work gets done in the 2.2.x series, but
> > with
> > very little scrutiny, and the proposal looks less scary because it
> changes
> > less
> > code. Seems like a trick, that's why I called it the "trojan horse".
>
> If so every iterative approach is so too.
>

Iterative on trunk is fine.


>
> >
> > Even if you "promise" not to do any of these changes in the 2.2.x series
> the
> > fact remains that these changes are getting in very late in the game,
> after
> > 3 months since I asked to start the release process and was told to wait
> > "two weeks".
> I don't "promise". I _consult_ with the PSC about the feasibility of
> getting any of this into the 2.2.x series, and obey the PSC decision.
> I don't remember having told you to wait for two weeks to get GSIP69
> in place for 2.2.x. Rather the contrary, I remember having told you
> this work was not targeting 2.2.x but a new trunk. If later in the
> game I ask the PSC what the opinion is about doing so, I don't see
> what's disrespectful about asking. If, on the contrary, I did ever
> told you to wait for two week with regard to GSIP69, I very much
> apologize.
>

You were not the one telling me to wait two weeks, Justin was.
It's the sum of having had to wait months first and then getting another
proposal in that made me snap.

Anyways, the above has been clarified already,
and if we get the timed releases proposals going we'll eradicate
the very possibility of finding ourselves in this rut again in the future.

Cheers
Andrea

-- 
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy

phone: +39 0584 962313
fax:  +39 0584 962313
mob:+39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] GSIP 69 - Catalog scalability enhancements - OGC Filters VS predicate

[Gabriel Roldan]

On Thu, May 3, 2012 at 2:02 PM, Andrea Aime
 wrote:
> On Thu, May 3, 2012 at 6:12 PM, Gabriel Roldan  wrote:
>>
>> All this said, I re-enforce this is a design decision I'm willing to
>> concede on and switch to OGC Filter. The only real blocker IMHO is the
>> inability to easily extend in-place, but having to use Catalog
>> specific function factories, flooding the general purpose filters with
>> catalog specific ones, or rather having to give up execution of
>> predicates on the backend and being forced to iterate (over a lot of
>> objects) in place, apply the in-process filtering on the client code,
>> and be exposed to unnecesary wrapping from catalog decorators.
>
>
> Read it all, I agree more or less with the pro/cons statements but not with
> the value judgements, to me the pros in using OGC filter model far
> overwheight the points in favor of the Predicate and the opposite happens
> for the limitations.
> I guess we can agree to disagree, and we'll need the rest of the PSC
> to act as a tie breaker.
>
> About the ability to extract properties out of the catalog objects, I
> believe we
> can get 90% there using BeanUtils inside a property extractor that activates
> when
> the object to be evaluated is a CatalogInfo, in fact the syntax you are
> using today to
> specify the nested property names is the same as the BeanUtils one (which
> is, btw,
> already in the classpath).
>
> About the need to have to roll a lot of filter functions... some of the
> things we need
> can be managed as properties using custom property extractors, as for the
> others I'm wondering if we cannot just roll anonymous filter functions.
> The reasons to have registered functions are:
> - being able to turn them into CQL/XML. Something we don't need, we would
>   not be able to do so with Predicate anyways
> - deep clone filters, again, something we won't be able to do with Predicate
> anyways
>
> Soo... what's preventing us from having a PredicateFunction base class that
> lets
> us generate a new filter function implementation inline as follows:
>
> new PredicateFunction() {
>   Object  evaluate(Object feature) {
>      return ((ResourceInfo)).enabled();
>   }
> }
>

I can live with that. The "breakage" of the OGC Filter usage pattern
would be confined to the org.geoserver.catalog package so... as long
as everybody is happy with that, it's ok to me.
Glad we're getting to an agreement.

Cheers,
Gabriel

> Instead of rolling a whole new API and code set we'd just have to roll some
> documentation
> bits on how the catalog subsystem manages the OGC filters.
> To me it's so much better it's a no brainer, although I understand you have
> a different set
> of values and thus a different opinion.
>
> Cheers
> Andrea
>
> --
> Ing. Andrea Aime
> GeoSolutions S.A.S.
> Tech lead
>
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
>
> phone: +39 0584 962313
> fax:      +39 0584 962313
> mob:    +39 339 8844549
>
> http://www.geo-solutions.it
> http://geo-solutions.blogspot.com/
> http://www.youtube.com/user/GeoSolutionsIT
> http://www.linkedin.com/in/andreaaime
> http://twitter.com/geowolf
>



-- 
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] W3DS Implementation up and running

[Nuno Miguel Carvalho Oliveira]

Hi Justin,

I'm really sorry about the patch i haven't seen the formatting trick (sorry
for the waste of time).
I send in annex two patchs one who makes the changes in the existing
classes and another to add the PostGIS 3D tests.

I hope i did it well this time.

Regards,

Nuno Oliveira




2012/5/3 Justin Deoliveira 

> Hi Nuno,
>
> The changes make sense, unfortunately the patch still has issues. The
> patch contains largely formatting changes. Looks like spaces were converted
> to tabs at some point. This unfortunately makes it nearly impossible to
> figure out what actually changed in that class. Seems to be mostly
> the PostGISDialect class, but also the test classes contain misformatting
> in terms of tabs vs spaces.
>
> Not sure what IDE you are using but if you are using eclipse there are
> existing formatting templates that will help with this. See this for more
> details.
>
>   http://docs.geotools.org/latest/developer/conventions/code/style.html
>
> Again, to reiterate, for any patches that are proposed it is imperative
> that they only contain relevant changes, and no formatting changes.
>
> -Justin
>
>
> On Wed, May 2, 2012 at 8:22 AM, Nuno Miguel Carvalho Oliveira <
> nmco51...@gmail.com> wrote:
>
>> Hi,
>>
>> (Sorry for the late reply, i had a very very busy week).
>>
>> First, thank you for your very complete answer.
>> I create a new patch based on your advices (in annex).
>> Basically to read 3D coordinates from a PostGIS data
>> base we need to put a hint in the query:
>>
>>   Hints hints = query.getHints();
>>   hints.put(Hints.FEATURE_2D, Boolean.FALSE);
>>   query.setHints(hints);
>>
>> This hint will remove 'ST_Force_2D' from the final querry
>> and set the encode to 'ST_AsEWKB' instead of 'ST_AsBinary'.
>>
>> I run the tests and all works fine (PostGIS3DTest).
>>
>> To resume what i have changed:
>>
>> - SQLDialect.java and PostGISDialect.java: I extend the
>>   'encodeGeometryColumn' function to take also the 'Hints'
>>   as a parameter.
>> - JDBCDataStore.java: I give the 'Hints' as a parameter
>>   to the 'encodeGeometryColumn' function.
>> - PostGIS3DTest and PostGIS3DTestSetup: I add 3D tests
>>   to PostGIS.
>>
>>
>> Any suggestions are very welcome.
>>
>> Regards,
>>
>> Nuno Oliveira
>>
>>
>> 2012/4/21 Andrea Aime 
>>
>>> On Thu, Apr 19, 2012 at 7:01 AM, Nuno Miguel Carvalho Oliveira <
>>> nmco51...@gmail.com> wrote:
>>>
 Hi,

 Follows in anexe two patchs, one to integrate W3DS as a community
 module in GeoServer and another to GeoTools who  permits the acess of 3D
 data from a PostGIS data base. Related to the acess of 3D data in GeoTools
 maybe it exists a better way to do this, any idea is welcome.


>>> Hi,
>>> let's start discussing the Geotools patch, since it's really short.
>>> The patch is almost correct, but it's mis-using the hints somehow.
>>>
>>> Hints are used in the query as a way to tell the store that we'd
>>> like the returned objects to have some particular property, such as being
>>> built with a particular geometry factory, or being flat (2D).
>>> The geometry column user data is instead used to carry some extra info
>>> that describes it, such as the fact the column is a "geography" instead
>>> of a
>>> "geometry".
>>>
>>> Query hints are created per request and can vary over time, for example
>>> WMS will always ask for 2D geometries, whilst W3DS or WFS won't.
>>> Geometry descriptor attributes instead are structural, once set they
>>> describe
>>> something about the geometry column "forever".
>>>
>>> As such you should not mix them, otherwise one request can force the
>>> geometry to be 2d by attaching the hint and the next request looking for
>>> 3d data won't get it (because the hint is already in place).
>>> To do what you want is better to extend the encodeGeometryColumn in
>>> SQLDialect  to take also the Hints as a parameter: it is an API break
>>> that
>>> I believe we can take on trunk (Justin, thoughts?).
>>>
>>> The other thing that's missing is a test.
>>> The JDBC testing framework is shared between all the databases and is
>>> setup so that there is a base abstract class which needs to be subclasses
>>> and return a "test setup" object that knows how to setup the expected
>>> spatial tables with the DDL specific of that particular database.
>>> You can extend JDBC3DTest and JDBC3DTestSetup, which are
>>> now implemented only for Oracle and DB2, and create an implementation
>>> for PostGIS.
>>>
>>> I'll try to have a look at the W3DS community module too, but as long as
>>> it's a
>>> community module you don't really need to pass any review.
>>> One thing is important tough, in order for GeoServer to include your
>>> module
>>> in the future you, or the company/authority/adminstration that employs
>>> you
>>> have to sign and send a "copyright assignment" contract that gives
>>> Openplans,
>>> the no-profit managing GeoServer, rights on the source code that you
>>> created.
>>> T

Re: [Geoserver-devel] GSIP 69 - Catalog scalability enhancements - OGC Filters VS predicate

[Andrea Aime]

On Thu, May 3, 2012 at 6:12 PM, Gabriel Roldan  wrote:

> All this said, I re-enforce this is a design decision I'm willing to
> concede on and switch to OGC Filter. The only real blocker IMHO is the
> inability to easily extend in-place, but having to use Catalog
> specific function factories, flooding the general purpose filters with
> catalog specific ones, or rather having to give up execution of
> predicates on the backend and being forced to iterate (over a lot of
> objects) in place, apply the in-process filtering on the client code,
> and be exposed to unnecesary wrapping from catalog decorators.
>

Read it all, I agree more or less with the pro/cons statements but not with
the value judgements, to me the pros in using OGC filter model far
overwheight the points in favor of the Predicate and the opposite happens
for the limitations.
I guess we can agree to disagree, and we'll need the rest of the PSC
to act as a tie breaker.

About the ability to extract properties out of the catalog objects, I
believe we
can get 90% there using BeanUtils inside a property extractor that
activates when
the object to be evaluated is a CatalogInfo, in fact the syntax you are
using today to
specify the nested property names is the same as the BeanUtils one (which
is, btw,
already in the classpath).

About the need to have to roll a lot of filter functions... some of the
things we need
can be managed as properties using custom property extractors, as for the
others I'm wondering if we cannot just roll anonymous filter functions.
The reasons to have registered functions are:
- being able to turn them into CQL/XML. Something we don't need, we would
  not be able to do so with Predicate anyways
- deep clone filters, again, something we won't be able to do with
Predicate anyways

Soo... what's preventing us from having a PredicateFunction base class that
lets
us generate a new filter function implementation inline as follows:

new PredicateFunction() {
  Object  evaluate(Object feature) {
 return ((ResourceInfo)).enabled();
  }
}

Instead of rolling a whole new API and code set we'd just have to roll some
documentation
bits on how the catalog subsystem manages the OGC filters.
To me it's so much better it's a no brainer, although I understand you have
a different set
of values and thus a different opinion.

Cheers
Andrea

-- 
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy

phone: +39 0584 962313
fax:  +39 0584 962313
mob:+39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] GSIP 69 - Catalog scalability enhancements - OGC Filters VS predicate

[Gabriel Roldan]

Hi Andrea, all.,

first off, sorry it took me so long to reply to this important thread,
and thanks Andrea again for splitting out the discussion into separate
topics

On Sat, Apr 28, 2012 at 10:47 AM, Andrea Aime
 wrote:
> Hum... the thread is getting long and mails deal with many topics, let met
> try to
> split this into separate sub-threads.
> This one is about filters, paging and sorting.
>
> About sorting I believe we are all on the same page, my suggestions
> about checking for fast sorting was just a random idea anyways,
> don't see any strong need to see it implemented.
yep, already decided to get rid of Catalog.canSort() based on feedback.

You make some good points, lets go to the most important one first,
Predicate vs OGC Filter:

To start with, I do am willing to concede on using OGC Filter instead
of the "domain specific" Predicate interface. Have a couple usability
concerns though, more about this later.

I do know it is a general purpose filter predicate language, coming
from GeoTools, which we already depend on. When I mention it as a
dependency I mean at the architectural level, not at the classpath
level. And also know from experience that our Filter implementation
works on non-feature object models, given appropriate property
extractors. If we go that route, we'll probably need a Catalog domain
specific (i.e., *Info) property extractor.

I do understand OGC Filter is richer and more expressive than the
(purposedly) limited number of "well known" Predicate idioms. More
about rationale later.

Your argument about ease of encoding Filter because we already have
code to do that, applies, AFAIK, to a specific data model (flat
table), at least in practice, except if you want to use app-schema. It
is not a bad argument, just falling on the implementation detail side
of the fence. I faithfuly assume you value the decoupling of the
interface from the underlying data model, so nothing to add here.
About the availability of filter splitters, that's indeed a very nice
bonus point for the OGC Filter choice.

The argument about lack of spatial filtering in Predicate is
debatible. The reason there are no well known spatial predicates in
the proposal is because the set of proposed well known constructs is
strictly limited to fit the current use of Catalog. That is, equals,
"iLike", and, or, exists, isNull. Nothing impedes adding spatial
constructs once the real need for them arise, but if you want them
executed by the storage engine, then that also meants imposing a new
requirement on the catalog backend, to support spatial queries, which
currently is not a requirement. If, by the other hand, you want
spatial filters without imposing the backend to support spatial, then
it's just as easy to create a predicate as an anonymous inner class.

In order to make this as short as possible: a possible CSW
implementation on top of the GeoServer Catalog, ability to specify a
CQL filter as a GetCapabilities parameter, ability to wrap the Catalog
as a DataStore and hence draw maps of where the layers are and expose
that information through WFS, are all really nice ideas. I want to
make clear I'm not against any of those, and actually encourage that
kind of feedback whenever a new proposal is made, since that's how we
as a community ensure our product serves everyone's needs. On the
other side, the best way we know so far to make things happen, is to
tie ourselves to an iterative and incremental development process. The
focus of GSIP69 is to solve today's GeoServer scalability problems.
Nonetheless, this kind of feedback is valuable in terms of planning
ahead for extensibility. So thanks for bringing up those points. That
said, I don't really see any of those new feature ideas as blockers
for having a domain specific query constructs for the Catalog. But
think it's pointless to develop too deep on each of them right now,
but acknowledge the current infrastructure to work with OGC Filters
would be convenient, instead of translating CQL to Predicate,
regardless of not being hard at all, indeed looks like unnecessary
duplication.

So, down to the core of this discussion, what we're essentially
discussing about is a design decision. I am sorry it seemed like the
one I made was lightly taken. It was not, which doesn't mean it was
the most accurate either. I seriously considered our already available
OGC Filter implementation as the first choice, as it seems to fit
naturally, or rather easily.
Please note though, the proposal is on "under discussion" status, so
that's exactly what should be happening. Hence I'm glad we're doing
so, ad I'd like to see this kind of discussions as I found myself
often looking at bad smelling pieces of code throughout our codebase.
Including, of course, my own code.

All that said, I think it's turn to weight in both options so we can
take a decision knowing what the benefits and drawbacks are for each
one.

The following is _my_ current thinking on both approaches. Feel free
to complete/corr

Re: [Geoserver-devel] GSIP 69 - Catalog scalability enhancements - proof of concept

[Gabriel Roldan]

On Sat, Apr 28, 2012 at 11:30 AM, Andrea Aime
 wrote:
> Moving forward with the discussion about the code being "proof of concept".
>
> By "proof of concept" I don't mean that the code is bad, I mean that it's a
> stage
> where it proofs the concept but it's not ready to be integrated in a code
> based that was meant to become stable soon, simply because it's last minute
> (last minute changes are rarely good) and imcomplete.
Well, the "soon to be stable" 2.2 branch is out of the question.
Question is whether we'll allow progress to occur in the "soon to be
trunk" 2.3 branch, or (surprisingly) everything needs to be nailed
down to the minimal detail to allow new development to happen on
trunk.

>
> This one is mostly about what's happening above the catalog.
> Right now we have some exemplar use cases, which have been indeed picked up
> with care.
> However they are only three, that's my biggest worry, I'm pretty sure that
> by
> developing the full switch you might have seen more use cases and found more
> bugs in the implementations.
>
> Now, in order to reap the benefits of the scalable API one has to make the
> code
> actually use the new scalable methods whenever large amounts of data is read
> from the catalog, meaning switching also most other capabilities documents,
> the Describe* methods (most of them can take no layer/coverage/feature type
> identifier and describe the whole server as a result), the GUI, I guess
> some parts of RESTConfig.

I judged smarter to identify the driving use cases first rather than
go an update the whole code base in one shot.
Note the use cases are meant to be representative of all the
(existing) different uses of the catalog where scalability is a
concern. If you can identify more, then that would be awesome.
For instance, the three ones picked up represent the cases where:
- you need to process either the full list of a given type or
resource, or rather using some simple filtering and sorting. The
example is GetCaps, but applies also to Describe* and RESTConfig's
lists of resources.
- paging, filtering with and "iLike" like predicate, and sorting: GUI
- client side full scans where part of the filter is encodable and
part not, and that usually implies building a lot of objects to then
be discarded: SecureCatalog

With that in place, it looks like it'd be possible to migrate the rest
of the offending code where those usage patterns apply. May be it's
not so a good idea, it seemed to be to me and to the people inside
OpenGeo whom I validated the proposal with before going public with
it.

>
> Now, let's say we commit the proposal as it is now, with only the exemplar
> cases.
> You argue it is done to minimize the risk. I say the net effect is that
> it actually makes it way too easy, if not natural, to do all of the above
> work outside of the proposal framework with little scrutiny, because
> everything
> related to scalability is turned to "bug" or "improvement" jiras, forgetting
> that
> these jira wire up with code that is not as well tested as the rest, and
> thus
> put us at risk of getting something fundamentally broken while we are
> doing bugfix releases.

I see your point. While the proposal keeps on under discussion status,
I see no problem on start porting more stuff over on the proposal's
branch? Yet we needed the proposal to go out of incubation, so I think
it has been a good approach: gather all this feedback earlier in the
process instead of going public with it once we have migrated
everything/

> So in the end the same amount of work gets done in the 2.2.x series, but
> with
> very little scrutiny, and the proposal looks less scary because it changes
> less
> code. Seems like a trick, that's why I called it the "trojan horse".

If so every iterative approach is so too.

>
> Even if you "promise" not to do any of these changes in the 2.2.x series the
> fact remains that these changes are getting in very late in the game, after
> 3 months since I asked to start the release process and was told to wait
> "two weeks".
I don't "promise". I _consult_ with the PSC about the feasibility of
getting any of this into the 2.2.x series, and obey the PSC decision.
I don't remember having told you to wait for two weeks to get GSIP69
in place for 2.2.x. Rather the contrary, I remember having told you
this work was not targeting 2.2.x but a new trunk. If later in the
game I ask the PSC what the opinion is about doing so, I don't see
what's disrespectful about asking. If, on the contrary, I did ever
told you to wait for two week with regard to GSIP69, I very much
apologize.

> As much as you feel my feedback is unfair, try to put on the other plate of
> the
> scale how much unfair it has been already for me.

Please, explain how the GSIP 69 proposal has been unfair for you, so
that I'm more careful in the future.

>
> I'd much prefer to see the work done in a new trunk, done fully, done well,
> and eventually be backported later if we don't find a compromise on timed

Re: [Geoserver-devel] W3DS Implementation up and running

[Justin Deoliveira]

Hi Nuno,

The changes make sense, unfortunately the patch still has issues. The patch
contains largely formatting changes. Looks like spaces were converted to
tabs at some point. This unfortunately makes it nearly impossible to figure
out what actually changed in that class. Seems to be mostly
the PostGISDialect class, but also the test classes contain misformatting
in terms of tabs vs spaces.

Not sure what IDE you are using but if you are using eclipse there are
existing formatting templates that will help with this. See this for more
details.

  http://docs.geotools.org/latest/developer/conventions/code/style.html

Again, to reiterate, for any patches that are proposed it is imperative
that they only contain relevant changes, and no formatting changes.

-Justin

On Wed, May 2, 2012 at 8:22 AM, Nuno Miguel Carvalho Oliveira <
nmco51...@gmail.com> wrote:

> Hi,
>
> (Sorry for the late reply, i had a very very busy week).
>
> First, thank you for your very complete answer.
> I create a new patch based on your advices (in annex).
> Basically to read 3D coordinates from a PostGIS data
> base we need to put a hint in the query:
>
>   Hints hints = query.getHints();
>   hints.put(Hints.FEATURE_2D, Boolean.FALSE);
>   query.setHints(hints);
>
> This hint will remove 'ST_Force_2D' from the final querry
> and set the encode to 'ST_AsEWKB' instead of 'ST_AsBinary'.
>
> I run the tests and all works fine (PostGIS3DTest).
>
> To resume what i have changed:
>
> - SQLDialect.java and PostGISDialect.java: I extend the
>   'encodeGeometryColumn' function to take also the 'Hints'
>   as a parameter.
> - JDBCDataStore.java: I give the 'Hints' as a parameter
>   to the 'encodeGeometryColumn' function.
> - PostGIS3DTest and PostGIS3DTestSetup: I add 3D tests
>   to PostGIS.
>
>
> Any suggestions are very welcome.
>
> Regards,
>
> Nuno Oliveira
>
>
> 2012/4/21 Andrea Aime 
>
>> On Thu, Apr 19, 2012 at 7:01 AM, Nuno Miguel Carvalho Oliveira <
>> nmco51...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> Follows in anexe two patchs, one to integrate W3DS as a community module
>>> in GeoServer and another to GeoTools who  permits the acess of 3D data from
>>> a PostGIS data base. Related to the acess of 3D data in GeoTools maybe it
>>> exists a better way to do this, any idea is welcome.
>>>
>>>
>> Hi,
>> let's start discussing the Geotools patch, since it's really short.
>> The patch is almost correct, but it's mis-using the hints somehow.
>>
>> Hints are used in the query as a way to tell the store that we'd
>> like the returned objects to have some particular property, such as being
>> built with a particular geometry factory, or being flat (2D).
>> The geometry column user data is instead used to carry some extra info
>> that describes it, such as the fact the column is a "geography" instead
>> of a
>> "geometry".
>>
>> Query hints are created per request and can vary over time, for example
>> WMS will always ask for 2D geometries, whilst W3DS or WFS won't.
>> Geometry descriptor attributes instead are structural, once set they
>> describe
>> something about the geometry column "forever".
>>
>> As such you should not mix them, otherwise one request can force the
>> geometry to be 2d by attaching the hint and the next request looking for
>> 3d data won't get it (because the hint is already in place).
>> To do what you want is better to extend the encodeGeometryColumn in
>> SQLDialect  to take also the Hints as a parameter: it is an API break that
>> I believe we can take on trunk (Justin, thoughts?).
>>
>> The other thing that's missing is a test.
>> The JDBC testing framework is shared between all the databases and is
>> setup so that there is a base abstract class which needs to be subclasses
>> and return a "test setup" object that knows how to setup the expected
>> spatial tables with the DDL specific of that particular database.
>> You can extend JDBC3DTest and JDBC3DTestSetup, which are
>> now implemented only for Oracle and DB2, and create an implementation
>> for PostGIS.
>>
>> I'll try to have a look at the W3DS community module too, but as long as
>> it's a
>> community module you don't really need to pass any review.
>> One thing is important tough, in order for GeoServer to include your
>> module
>> in the future you, or the company/authority/adminstration that employs you
>> have to sign and send a "copyright assignment" contract that gives
>> Openplans,
>> the no-profit managing GeoServer, rights on the source code that you
>> created.
>> This is necessary to keep the ownership in one place and defend GeoServer
>> in
>> court should a license violation arise.
>>
>> Cheers
>> Andrea
>>
>> --
>> ---
>> Ing. Andrea Aime
>> GeoSolutions S.A.S.
>> Tech lead
>>
>> Via Poggio alle Viti 1187
>> 55054  Massarosa (LU)
>> Italy
>>
>> phone: +39 0584 962313
>> fax:  +39 0584 962313
>> mob:+39 339 8844549
>>
>> http://www.geo-solutions.it
>> http://

Re: [Geoserver-devel] wms.xml, wfs.xml, wcs.xml wps.xml files get cleared of content making services unavailable

[Justin Deoliveira]

Hi Robert,

I don't know of any outstanding jira ticket specifically for this issue.
You could try a newer version and see if the problem persists.

All in all your best bet is going to be to try as best you can to reliably
reproduce the problem and then find a way to have a developer reproduce the
problem. Without that I am not sure what can be done.

Perhaps you can try to set up a watcher script that notifies when the files
are flushed away. And perhaps in parallel to that turn on request level
logging in your servlet container and try to compare timestamps to see
indeed what is going on and perhaps what lead to it.

-Justin

On Wed, May 2, 2012 at 2:50 PM, Brister, Robert L
wrote:

>  Issue: 
>
> We have an issue where the wms.xml, wfs.xml, wcs.xml and wps.xml files in
> GeoServer from time to time get cleared of content, thus resulting in no
> services being available.
>
> ** **
>
> Environment:
>
>We have 2 environments. Both exhibit the issue.
>
> **1)  **Environment 1
>
> **a.   **GeoServer version 2.1.x
>
> **b.  **Running on RHEL 5.7
>
> **c.   **JBoss 5.1
>
> **d.  **Clustered configuration
>
> **
> i.  **4 GeoServer Instances clustered sharing global file external
> data directory
>
> **
> ii.  **F5 Load balancer in front of the GeoServers.
>
> **2)  **Environment 2
>
> **a.   **GeoServer version 2.1.x
>
> **b.  **Running on RHEL 5.7
>
> **c.   **JBoss 5.1
>
> **d.  **Clustered configuration
>
> **
> i.  **2 GeoServers Clustered, sharing global file external data
> directory
>
> **
> ii.  **F5 Load balancer in front of the GeoServers.
>
> Theory:
>
> We ‘think’ this may be triggered by a rest reload command.
>
> We do a reset reload command because we use the rest interface to create
> new layers.  The call is made via one of the clustered GeoServers, and a
> reload of the other GeoServers in the cluster is required in order for them
> to become aware of the newly created layers.
>
> It has been our observation that a back-to-back reload command often
> precedes the issue occurring.
>
> ** **
>
> Request:
>
> I attempted to see if this issue has been reported as bug in the Jira
> system, but did not find a report that I thought was a match.
>
> Has anyone else experienced this issue?
>
> Is there an existing bug report for this issue?
>
> Has this issue be addressing in a newer release?
>
> Any ideas?
>
> ** **
>
> Thanks in advance.
>
> ** **
>
> Respectfully,
>
> ** **
>
> Chris Moreau
>
> ** **
>
> ** **
>
> ** **
>
> Robert L Brister
> Principal Software Engineer
> General Dynamics Information Technology
> FNMOC, Monterey, CA
> Building 704, Rm 235
> Ph: 831-656-5056
> Cell: 408-569-5954
> robert.bris...@gdit.com
>
> ** **
>
> UNCLASSIFIED//FOR OFFICIAL USE ONLY//
>
> ** **
>
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>


-- 
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] [Geotools-devel] Discussing a switch to a time boxed release model

[Andrea Aime]

On Thu, May 3, 2012 at 4:57 PM, Justin Deoliveira wrote:
>
>
> I am not sure we need a full blown proposal for the automation stuff, but
> i guess it can't hurt, if anything it will help specify what the
> imports/outputs are. In my head the idea is to have a new job that takes a
> revision and a README description and basically that would be it. A bunch
> of core artifacts would spit out the opposite end.
>
> Taking it further will be automating the osx and win installers jobs, for
> which we have machines that would be suitable for this already.
>
> I am happy to script it out, if i find i can't do it in a reasonable
> amount of time I will try to find some help. I actually would like to store
> all of our build scripts from hudson in version control anyways so anyone
> can hack on them easily, this seems like a good time to do that.
>

Yep, that sounds cool. Let me know how I can help.

I also agree I don't see the need for a full blown GSIP, maybe better to
use the time to hash out the scripts.
The time boxed model instead really needs a management comitee vote, thus
we'll really need to make a proposal for it.

Cheers
Andrea

-- 
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy

phone: +39 0584 962313
fax:  +39 0584 962313
mob:+39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] [Geotools-devel] Discussing a switch to a time boxed release model

[Justin Deoliveira]

On Thu, May 3, 2012 at 4:52 AM, Andrea Aime wrote:

> On Thu, May 3, 2012 at 12:32 PM, Chris Holmes  wrote:
>
>> +1 on all this.
>>
>> Perhaps two GSIP's should come out of this? One for the release model
>> / schedule. And then another for automation improvements? Or perhaps
>> we don't need a GSIP for that, but should get a jira and a plan of
>> attack for it.
>>
>
> The proposed model is quite "release happy", so if we don't have the
> automation
> it's not going to be feasible.
> We can have two GSIPs, first the automation one, once it's there we
> can do the release schedule one?
>
> I can help for the automation one too (within the limits of what
> can be done without direct access to the build server, that is).
>

I am not sure we need a full blown proposal for the automation stuff, but i
guess it can't hurt, if anything it will help specify what the
imports/outputs are. In my head the idea is to have a new job that takes a
revision and a README description and basically that would be it. A bunch
of core artifacts would spit out the opposite end.

Taking it further will be automating the osx and win installers jobs, for
which we have machines that would be suitable for this already.

I am happy to script it out, if i find i can't do it in a reasonable amount
of time I will try to find some help. I actually would like to store all of
our build scripts from hudson in version control anyways so anyone can hack
on them easily, this seems like a good time to do that.



> Cheers
> Andrea
>
>
> --
> Ing. Andrea Aime
> GeoSolutions S.A.S.
> Tech lead
>
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
>
> phone: +39 0584 962313
> fax:  +39 0584 962313
> mob:+39 339 8844549
>
> http://www.geo-solutions.it
> http://geo-solutions.blogspot.com/
> http://www.youtube.com/user/GeoSolutionsIT
> http://www.linkedin.com/in/andreaaime
> http://twitter.com/geowolf
>
>
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>


-- 
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] [jira] (GEOS-5088) GeoServer WPS would execute at most one asynch request at a time

[Andrea Aime (JIRA)]

Andrea Aime created GEOS-5088:
-

 Summary: GeoServer WPS would execute at most one asynch request at 
a time
 Key: GEOS-5088
 URL: https://jira.codehaus.org/browse/GEOS-5088
 Project: GeoServer
  Issue Type: Bug
  Components: WPS
Affects Versions: 2.1.3
Reporter: Andrea Aime
Assignee: Andrea Aime
 Fix For: 2.1.4


Debugging shows the requests are queued and executed serially instead of being 
executed in parallel with the configured level of parallelism

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] [Geotools-devel] Discussing a switch to a time boxed release model

[Andrea Aime]

On Thu, May 3, 2012 at 12:32 PM, Chris Holmes  wrote:

> +1 on all this.
>
> Perhaps two GSIP's should come out of this? One for the release model
> / schedule. And then another for automation improvements? Or perhaps
> we don't need a GSIP for that, but should get a jira and a plan of
> attack for it.
>

The proposed model is quite "release happy", so if we don't have the
automation
it's not going to be feasible.
We can have two GSIPs, first the automation one, once it's there we
can do the release schedule one?

I can help for the automation one too (within the limits of what
can be done without direct access to the build server, that is).

Cheers
Andrea


-- 
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy

phone: +39 0584 962313
fax:  +39 0584 962313
mob:+39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] [Geotools-devel] Discussing a switch to a time boxed release model

[Chris Holmes]

+1 on all this.

Perhaps two GSIP's should come out of this? One for the release model
/ schedule. And then another for automation improvements? Or perhaps
we don't need a GSIP for that, but should get a jira and a plan of
attack for it.

On Thu, May 3, 2012 at 5:08 AM, Alessio Fabiani
 wrote:
> Hi all,
> I really would like to move forward with this proposal.
>
> I'm currently having a lot of difficulties to get an idea of a plan on wich
> version of GeoServer/GeoTools schedule on my projects, so having a
> programmatic release project would be very welcomed and useful.
>
> High automation also is a great idea, would very very helpful for the
> release process which usually takes a lot of time and resources.
>
> I also volunteer to provide help as much as possible to have all of this
> implemented soon.
>
> Regards,
>         Alessio.
>
> ---
> Ing. Alessio Fabiani
> Founder / CTO GeoSolutions S.A.S.
>
> GeoSolutions S.A.S.
>
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
>
> phone: (+39) 0584 96.23.13
> fax:     (+39) 0584 96.23.13
> mobile:(+39) 331 62.33.686
>
> http://www.geo-solutions.it
> http://geo-solutions.blogspot.com
> http://www.linkedin.com/in/alessiofabiani
> https://twitter.com/alfa7961
> http://twitter.com/geosolutions_it
> ---
>
>
>
> On Wed, May 2, 2012 at 6:27 PM, Andrea Aime 
> wrote:
>>
>> On Tue, May 1, 2012 at 5:54 PM, Justin Deoliveira 
>> wrote:
>>>
>>> In general I think it looks great, a few things though. I think given the
>>> current effort to put out releases 1 month is probably asking a bit much
>>> given the resources we have on the project. So I think to do one month
>>> cycles we really do need to better automate our release process with a
>>> hudson job that does most of the work.
>>>
>>> It would also be good to have some better defined (and perhaps stricter)
>>> guidelines about what is acceptable to commit given the current phase of an
>>> iteration. For instance obviously once we move to a stable or hardening
>>> phase GSIP's that drastically alter the core are out of the question. It
>>> would be good if we had a more concrete definition of "drastically alter the
>>> core". Like should we be strict and say stable/hardening means strictly only
>>> bug fixes? With a faster release cycle it could make more sense to have
>>> stricter guidelines since if you don't get something into this release there
>>> is one not too far off. This is exactly why we ran into the fluerry of gsip
>>> issue... with another release 1.5 years away it certainly puts the pressure
>>> on to cram stuff in.
>>>
>>> Anyways, great stuff. I like where this is going, big things from my
>>> standpoint.
>>>
>>> 1. better automation of release, which i am happy to help with
>>> 2. better guidelines for what type of development is acceptable during
>>> what phases
>>
>>
>> Fully agree on the higher automation (tried to discuss some ideas about it
>> in my
>> original mail).
>>
>> About what is acceptable and not, what about the following:
>> - stable series: only bug fixes and new features that do not require API
>> changes
>>   or large patches to existing systems (that is, if you are contributing a
>> new module
>>   the patch can be as large as you want, but a "bug fix" that rewrites
>> half of WFS
>>   is not welcomed unless the PSC really really wants such change badly in)
>> - trunk: free reign, but large changes still need a GSIP and reviews
>> - hardening: no new features, only bug fixing to make sure people
>> concentrate on
>>   that, if you have something new it has to go on trunk for the time being
>>
>> The above should be, imho, taken more or less as strict rules that the PSC
>> should
>> try to enforce (the above, or whatever we come up with).
>> That said, the PSC should be allowed to decide outside of the above rules
>> in case of dire necessity (e.g., something that could threaten or damage
>> the
>> project severely if not done outside of the rules).
>>
>> Cheers
>> Andrea
>>
>> --
>> ---
>> Ing. Andrea Aime
>> GeoSolutions S.A.S.
>> Tech lead
>>
>> Via Poggio alle Viti 1187
>> 55054  Massarosa (LU)
>> Italy
>>
>> phone: +39 0584 962313
>> fax:      +39 0584 962313
>> mob:    +39 339 8844549
>>
>> http://www.geo-solutions.it
>> http://geo-solutions.blogspot.com/
>> http://www.youtube.com/user/GeoSolutionsIT
>> http://www.linkedin.com/in/andreaaime
>> http://twitter.com/geowolf
>>
>> ---
>>
>>
>> --
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/ja

Re: [Geoserver-devel] [Geotools-devel] Discussing a switch to a time boxed release model

[Alessio Fabiani]

Hi all,
I really would like to move forward with this proposal.

I'm currently having a lot of difficulties to get an idea of a plan on wich
version of GeoServer/GeoTools schedule on my projects, so having a
programmatic release project would be very welcomed and useful.

High automation also is a great idea, would very very helpful for the
release process which usually takes a lot of time and resources.

I also volunteer to provide help as much as possible to have all of this
implemented soon.

Regards,
Alessio.

---
Ing. Alessio Fabiani
Founder / CTO GeoSolutions S.A.S.

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy

phone: (+39) 0584 96.23.13
fax: (+39) 0584 96.23.13
mobile:(+39) 331 62.33.686

http://www.geo-solutions.it
http://geo-solutions.blogspot.com
http://www.linkedin.com/in/alessiofabiani
https://twitter.com/alfa7961
http://twitter.com/geosolutions_it
---



On Wed, May 2, 2012 at 6:27 PM, Andrea Aime wrote:

> On Tue, May 1, 2012 at 5:54 PM, Justin Deoliveira wrote:
>
>> In general I think it looks great, a few things though. I think given the
>> current effort to put out releases 1 month is probably asking a bit much
>> given the resources we have on the project. So I think to do one month
>> cycles we really do need to better automate our release process with a
>> hudson job that does most of the work.
>>
>> It would also be good to have some better defined (and perhaps stricter)
>> guidelines about what is acceptable to commit given the current phase of an
>> iteration. For instance obviously once we move to a stable or hardening
>> phase GSIP's that drastically alter the core are out of the question. It
>> would be good if we had a more concrete definition of "drastically alter
>> the core". Like should we be strict and say stable/hardening
>> means strictly only bug fixes? With a faster release cycle it could make
>> more sense to have stricter guidelines since if you don't get something
>> into this release there is one not too far off. This is exactly why we ran
>> into the fluerry of gsip issue... with another release 1.5 years away it
>> certainly puts the pressure on to cram stuff in.
>>
>> Anyways, great stuff. I like where this is going, big things from my
>> standpoint.
>>
>> 1. better automation of release, which i am happy to help with
>> 2. better guidelines for what type of development is acceptable during
>> what phases
>>
>
> Fully agree on the higher automation (tried to discuss some ideas about it
> in my
> original mail).
>
> About what is acceptable and not, what about the following:
> - stable series: only bug fixes and new features that do not require API
> changes
>   or large patches to existing systems (that is, if you are contributing a
> new module
>   the patch can be as large as you want, but a "bug fix" that rewrites
> half of WFS
>   is not welcomed unless the PSC really really wants such change badly in)
> - trunk: free reign, but large changes still need a GSIP and reviews
> - hardening: no new features, only bug fixing to make sure people
> concentrate on
>   that, if you have something new it has to go on trunk for the time being
>
> The above should be, imho, taken more or less as strict rules that the PSC
> should
> try to enforce (the above, or whatever we come up with).
> That said, the PSC should be allowed to decide outside of the above rules
> in case of dire necessity (e.g., something that could threaten or damage
> the
> project severely if not done outside of the rules).
>
> Cheers
> Andrea
>
> --
> ---
> Ing. Andrea Aime
> GeoSolutions S.A.S.
> Tech lead
>
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
>
> phone: +39 0584 962313
> fax:  +39 0584 962313
> mob:+39 339 8844549
>
> http://www.geo-solutions.it
> http://geo-solutions.blogspot.com/
> http://www.youtube.com/user/GeoSolutionsIT
> http://www.linkedin.com/in/andreaaime
> http://twitter.com/geowolf
>
> ---
>
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> GeoTools-Devel mailing list
> geotools-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Di