[Geoserver-devel] Fixing Catalog.getLayerGroupByName()

Hi Justin, all.

Remember the Catalog.getStyleByName() discussion? we knew
getLayerGroupByName() was next, so I cooked patch to hopefully
address its non-deterministic behavior sooner rather than later.
Please take a look at <http://jira.codehaus.org/browse/GEOS-5081&gt; at
your earliest convenience. Comments welcomed.

Cheers,
Gabriel

On Sun, Apr 15, 2012 at 7:08 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Cool, thanks for the explanation, you make good points. So yeah, +1 on the
change as i can;t think of any higher level use case and it does make the
contract more understandable, and easier to implement.

On Sun, Apr 15, 2012 at 6:02 PM, Gabriel Roldan <groldan@anonymised.com> wrote:

On Sun, Apr 15, 2012 at 6:43 PM, Gabriel Roldan <groldan@anonymised.com>
wrote:
>> Well the fact that test assertions are being changed sort of means
>> there is
>> a use case :slight_smile:
There is in the test cases. I started asking what the "real world" use
case is. If we are "fixing" the method contract, it makes sense to fix
it's test expectations accordingly (the unit test is checking the
class does "things right", but does it do "the right thing"?). So
yeah, back to the original question, I am not sure if this is "fixing"
at all, cause I'm not sure if there's some higher level use case
depending on it? It looks to me like there isn't, but as didn't design
the API I can't be sure. If the current behavior _is_ needed I'm more
than willing to stop wasting everybody's time (and refrain from
argumenting the API keeps being confusing).

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

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

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