Ok, makes sense. If the property filtering was somehow a security concern
I'd have pushed for using a blacklist, but I guess we're not too worried
about that since administrators must explicitly enable access to the
service by non-administrative users.
--
David Winslow
OpenGeo - http://opengeo.org/
On Thu, Dec 13, 2012 at 4:15 AM, Carlo Cancellieri <ccancelli...@hotmail.com
> wrote:
> David,
>
> > The configuration file seems a bit odd to me:
>
> I'm using it to avoid hardcoding of constants. If you think it is
> dangerous to expose it we can easily remove the datadir lookup.
> Note that this configuration should be considered a plus, in most cases this
> file may not be created at all.
>
> > # group(1) defines the name attribute of of the resource
> > resourceNameRegex=.+/(.*).(jar|war)
>
> > # list of properties to exclude from the resource
> >
> resourceAttributeExclusions=Import-Package,Export-Package,Class-Path,Require-Bundle
> >Why have a blacklist instead of a whitelist for filtering the published
> properties? (Actually, why do the properties need to be filtered at all?)
>
> This is intentionally done. I only want to be able to exclude some too
> verbose parameters leaving the resource properties list open. So users can
> add their jars (with custom properties) having the complete list of
> properties. The configuration is exposed to be able to be more verbose
> (removing exclusions at all).
>
> > # list of properties to include into the Version.
> > # [optionally] You can specify a replacement string for a property
> key:
> > # key:replace
> >
> versionAttributeInclusions=Project-Version:Version,Build-Timestamp,Git-Revision,Specification-Version:Version,Implementation-Version:Git-Revision
> >Why provide for rewriting version attribute names? (and what happens if
> multiple attributes end up with the same name after rewriting?)
>
> The model uses a map to store attributes so the last attribute found into
> the manifest file will be used.
> This is quite safe in my opinion since we are only using it in 'versions'
> (which exposes few and well known manifests files).
>
> I added this capability (rename) to align the output of the 'versions'
> request, due to differences in Manifest.mf files between:
>
> - GeoTools/GeoServer:
> --------------------------------
> Manifest-Version: 1.0
> Archiver-Version: Plexus Archiver
> Created-By: Apache Maven
> Built-By: jetty
> Build-Jdk: 1.6.0_21
> Build-Timestamp: 04-Dec-2012 02:31
> Git-Revision: 380a2b8545ee9221f1f2d38a4f10ef77a23bccae
> Project-Version: 9-SNAPSHOT
> Class-Path: gt-opengis-9-SNAPSHOT.jar jsr-275-1.0-beta-2.jar vecmath-1
> .3.2.jar commons-pool-1.5.4.jar jai_core-1.1.3.jar
> --------------------------------
>
> - GeoWebCache:
> --------------------------------
> Manifest-Version: 1.0
> Archiver-Version: Plexus Archiver
> Created-By: Apache Maven
> Built-By: jetty
> Build-Jdk: 1.6.0_21
> Implementation-Title: org.geowebcache
> Implementation-Vendor: http://geowebcache.org
> Implementation-Version: 2a534f91f6b99e5120a9eaa5db62df771dd01688/2a534
> f91f6b99e5120a9eaa5db62df771dd01688
> Specification-Title: org.geowebcache
> Specification-Vendor: http://geowebcache.org
> Specification-Version: 1.3-SNAPSHOT
> --------------------------------
>
> As you can see we have Implementation-Version in GeoWebCache and
> Git-Revision in GeoServer/GeoTools which should be exposed using the same
> name.
> The same happens for Specification-Version (GWC) and Project-Version
> (GT/GS).
>
> I appreciate your reply.
> Cheers,
> Carlo
>
> --
> David Winslow
> OpenGeo - http://opengeo.org/
>
>
> On Tue, Dec 11, 2012 at 2:12 PM, Carlo Cancellieri <
> ccancelli...@hotmail.com> wrote:
>
> Here is my rest version proposal:
> http://geoserver.org/pages/viewpage.action?pageId=55574531
>
> Feel free to post comments and remember to vote :)
>
> Best regards,
> Carlo Cancellieri - GeoSolutions SAS
>
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>
>
------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel