SLD param in getMap only works when NamedLayer.Name matches specied layer name with prefix included

From the SLD specification:

"It has already been described, in Section 6.2, how the LAYERS and STYLES parameters
could be encoded in an SLD. The request references the SLD using a SLD parameter,
which replaces the LAYERS and STYLES parameters. The SLD itself must be accessible
to the WMS and is identified using a URL."

SLD=url replaces both layers and styles parameters, so it must contain all information
needed to draw the map.

If there is one buggy behaviour here, it's that the kvp parser does not consider layers,styles
and sld mutually exclusive and does report an error.
Yet, since sld is not in the wms spec itself, I guess we cannot return an hard error (vendor
parameter should be ignored if they cannot be used)

What do you think?

Hmm... well looking at the GetMapKvpRequestReader it appears that you describe is called "nonLibraryMode", and only engages if there are no layers specified in the request. So if i interpret the above properly it should also engage whenever there is a SLD parameter supplied regardless of the layers and styles that are requested.

That's my interpretation of the spec indeed, not sure if it's correct thought. Chris, what do you think?

Moving to beta4, thought I think this should be closed as "won't fix". More feebdack appreciated. Chris?

Looking at the specification, the "library mode" engages when SLD or SLD_BODY are used in conjuction with layers=xxx

In this case, the spec says (page 10):

"When an SLD is used as a style library, the STYLES CGI parameter is interpreted in the
usual way in the GetMap request, except that the handling of the style names is organized
so that the styles defined in the SLD take precedence over the named styles stored within
the map server. The user-defined SLD styles can be given names and they can be marked
as being the default style for a layer. To be more specific, if a style named
?CenterLine? is referenced for a layer and a style with that name is defined for the
corresponding layer in the SLD, then the SLD style definition is used. Otherwise, the
standard named-style mechanism built into the map server is used. If the use of a default
style is specified and a style is marked as being the default for the corresponding layer in
the SLD, then the default style from the SLD is used; otherwise, the standard default style
in the map server is used"

In fact UserStyle has a "isDefault" attribute, which we don't use in default_polygon.sld, so
according to the spec states should be rendered with its own default style since the
referenced SLD does not contain a default one.

Justin, going back to the initial problem, I tried the following request:

http://localhost:8080/geoserver/wms?bbox=-130,24,-66,50&styles=population&Format=image/png&request=GetMap&layers=topp:states&width=550&height=250&srs=EPSG:4326&sld=http://localhost:8080/geoserver/styles/default_polygon.sld

and I get no exceptions. Only, the sld is ignored, which is correct when working in library mode btw, since default_polygon.sld does not contain a "default" style.
In fact the style is not even valid because it does not have a name. Yet, when I add it in the UserStyle (as "defaultPolygon", and issue the following request:
http://localhost:8080/geoserver/wms?bbox=-130,24,-66,50&styles=population&Format=image/png&request=GetMap&layers=topp:states&width=550&height=250&srs=EPSG:4326&sld=http://localhost:8080/geoserver/styles/default_polygon.sld&styles=defaultPolygon

nothing happens, because of a bug in the code. The specification says the name of the userlayer must be used, instead the code is using the name of the userlayer/namedlayer. This is one of the two actual bugs in there.

The other is that nothing checks for a "default" style to be used when layers=xxx,yyy is used an not style name is provided for one of the layers (having layers=xxx,yyy engages library mode anyways).

This behaviour has been wrong for ages... since we are under pressure with paid work, shall we move this one to 1.6.x?

sure