Hi,
working on the catalog configuration today I was greeted
by ModificationProxy throwing an exception because
FeatureTypeInfo returned a null collection for metadatalinks.
I've tried to patch that, but then the UI I have chockes on
it as well with another NPE.
To sum up, the assumption that xxxInfo object never returned
null collections (but empty ones instead) held true until
yesterday, but it's no more valid.
Was I playing with the wrong assumption (and so ModificationProxy?).
In fact looking in the javadocs of the xxxInfo objects I found
no assurances in that respect, but afaik that is considered
a good practice and apparently before the GSIP 34 hookup
it was true as well?
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Andrea Aime ha scritto:
In fact looking in the javadocs of the xxxInfo objects I found
no assurances in that respect, but afaik that is considered
a good practice and apparently before the GSIP 34 hookup
it was true as well?
Hum, considering the xxxInfo objects provide no setter for
collections, this looks actually like a bug. No way
to fill an empty collection 
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Andrea Aime ha scritto:
Andrea Aime ha scritto:
In fact looking in the javadocs of the xxxInfo objects I found
no assurances in that respect, but afaik that is considered
a good practice and apparently before the GSIP 34 hookup
it was true as well?
Hum, considering the xxxInfo objects provide no setter for
collections, this looks actually like a bug. No way
to fill an empty collection
Hmmm... I wiped out my data dir and started fresh, and I
cannot reproduce the issue anymore.
If I can reproduce and spot how it happens I'll let you
know.
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Hi Andrea,
This is an issue yes, and I think i know why it is happening. But first off, yes a collection should never be returned as null. And if you look at the implementation of any InfoImpl you should see that collections are always initialized with a value. The problem comes up with xstream persistance, because xstream does not use the constructor mechanism for creating the objects when it depersists.
So why is this happening. My guess is because the way the xstream persistance is set up when it writes out an object (in this case a feature type) it omits elements for empty collections. To avoid elements of the nature:
<metadata/>
<metadataLinks/>
etc... Now when the file is ready back in, the lack of these tags means that no value is initialized, and the collection is null.
To get around this issues, if you look at the CatalogImpl whenever an object is added to the catalog, it is "resolved" and any uninitialized collections are initialized.
And back to your initial problem, a check for metadataLinks is not being made. So it is an easy to fix. Will commit it shortly.
-Justin
Andrea Aime wrote:
Andrea Aime ha scritto:
Andrea Aime ha scritto:
In fact looking in the javadocs of the xxxInfo objects I found
no assurances in that respect, but afaik that is considered
a good practice and apparently before the GSIP 34 hookup
it was true as well?
Hum, considering the xxxInfo objects provide no setter for
collections, this looks actually like a bug. No way
to fill an empty collection
Hmmm... I wiped out my data dir and started fresh, and I
cannot reproduce the issue anymore.
If I can reproduce and spot how it happens I'll let you
know.
Cheers
Andrea
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Justin Deoliveira ha scritto:
Hi Andrea,
This is an issue yes, and I think i know why it is happening. But first off, yes a collection should never be returned as null. And if you look at the implementation of any InfoImpl you should see that collections are always initialized with a value. The problem comes up with xstream persistance, because xstream does not use the constructor mechanism for creating the objects when it depersists.
Right. Interesting, so, could the attach method we talked about
in a previous mail exchange be just a call to "resolve"?
What about making it public (just exploring options here).
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Andrea Aime wrote:
Justin Deoliveira ha scritto:
Hi Andrea,
This is an issue yes, and I think i know why it is happening. But first off, yes a collection should never be returned as null. And if you look at the implementation of any InfoImpl you should see that collections are always initialized with a value. The problem comes up with xstream persistance, because xstream does not use the constructor mechanism for creating the objects when it depersists.
Right. Interesting, so, could the attach method we talked about
in a previous mail exchange be just a call to "resolve"?
What about making it public (just exploring options here).
Yeah, I thought about this too as well. And while it would solve the problem that attach() is added for (ie, it sets the catalog on the object), the main purpose of resolve() is very implementation specific to the fact that we are using proxies. So I think in terms of what we make public, I think attach() makes more sense. Behind the scenes we can probably just have each attach() method call through to resolve().
Cheers
Andrea
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Justin Deoliveira ha scritto:
And back to your initial problem, a check for metadataLinks is not being made. So it is an easy to fix. Will commit it shortly.
Just noticed the same is happening for styles in a LayerInfo.
If all that's needed is a null check and setting the proper empty
collection, I can fix them as I find them.
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Andrea Aime wrote:
Justin Deoliveira ha scritto:
And back to your initial problem, a check for metadataLinks is not being made. So it is an easy to fix. Will commit it shortly.
Just noticed the same is happening for styles in a LayerInfo.
If all that's needed is a null check and setting the proper empty
collection, I can fix them as I find them.
Yup, all you need to do is update resolve() and add the check. You may need to update the appropriate InfoImpl class as well to add the setter method.
Cheers
Andrea
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.