[Geoserver-devel] Catalog objects and serialization

GeoServer GeoServer Developer
1

Hi,
I'm having some troubles with the catalog objects I'd like
to discuss.

There are a few catalog objects that do require some access
to GT2 provided information. For example, FeatureTypeInfo
can return a FeatureType, AttributeTypeInfo an AttributeDescriptor.
The way things are done now, that information provided
by some external entity during the object construction.

Which works fine only as long as the object is serialized
and deserialized... which happens when those objects are
used within Wicket models. Now, for pure editing a form
can be backed by a loadable/detachable model that will
grab again the same FeatureTypeInfo from the catalog,
it's more work, but it's doable.

What about a form that is editing a new FeatureTypeInfo
thought? That one is not in the catalog still, but
the FTI will be serialized as the page changes, and
if the user goes back, boom, the FTI gets deserialized,
but the FeatureType it contained is gone...

So, how to deal with it? Ideas:
1) Make those object talk to the catalog (make them
    a bit more active)
2) Mark a few properties as unsafe to use in the UI,
    and build models that know how to handle them?
Let me know

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

2

Andrea Aime wrote:

Hi,
I'm having some troubles with the catalog objects I'd like
to discuss.

There are a few catalog objects that do require some access
to GT2 provided information. For example, FeatureTypeInfo
can return a FeatureType, AttributeTypeInfo an AttributeDescriptor.
The way things are done now, that information provided
by some external entity during the object construction.

Which works fine only as long as the object is serialized
and deserialized... which happens when those objects are
used within Wicket models. Now, for pure editing a form
can be backed by a loadable/detachable model that will
grab again the same FeatureTypeInfo from the catalog,
it's more work, but it's doable.

Question, I thought we abandoned using straight serialization for catalog objects and instead adopted loadable detachable models, or is this just in some cases?

What about a form that is editing a new FeatureTypeInfo
thought? That one is not in the catalog still, but
the FTI will be serialized as the page changes, and
if the user goes back, boom, the FTI gets deserialized,
but the FeatureType it contained is gone...

So, how to deal with it? Ideas:
1) Make those object talk to the catalog (make them
    a bit more active)
2) Mark a few properties as unsafe to use in the UI,
    and build models that know how to handle them?
Let me know

I don't think I quite understand option 1, but I think I prefer option 2, with perhaps a spin:

a) omit properties that require the external resources, making them available only on an edit, or:

b) if the property is necessary on the new form, create a model that loads it "manually", ie not through the feature type. This is more or less what the old stuff did to get around this i believe

Cheers
Andrea

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

3

Justin Deoliveira ha scritto:

Andrea Aime wrote:

Hi,
I'm having some troubles with the catalog objects I'd like
to discuss.

There are a few catalog objects that do require some access
to GT2 provided information. For example, FeatureTypeInfo
can return a FeatureType, AttributeTypeInfo an AttributeDescriptor.
The way things are done now, that information provided
by some external entity during the object construction.

Which works fine only as long as the object is serialized
and deserialized... which happens when those objects are
used within Wicket models. Now, for pure editing a form
can be backed by a loadable/detachable model that will
grab again the same FeatureTypeInfo from the catalog,
it's more work, but it's doable.

Question, I thought we abandoned using straight serialization for catalog objects and instead adopted loadable detachable models, or is this just in some cases?

In some cases. You cannot use a loadable/detachable model
if there is nothing to detach, in particular, you cannot
detach a catalog object that has not been saved 'cause
there is nothing to reload from the catalog.
In this case, you're basically forced into saving the
object itself (or not?)

2) Mark a few properties as unsafe to use in the UI,
    and build models that know how to handle them?
Let me know

I don't think I quite understand option 1, but I think I prefer option 2, with perhaps a spin:

a) omit properties that require the external resources, making them available only on an edit, or:

b) if the property is necessary on the new form, create a model that loads it "manually", ie not through the feature type. This is more or less what the old stuff did to get around this i believe

Works for me, we just have a handful of these cases, so I guess
we can create reusable loadable/detachable models that know
how to re-instate the lost attribute programmatically on reload?
The candidates would be ResourceInfo and subclasses, by
extension LayerInfo (since it holds a ResourceInfo), and
AttributeTypeInfo? From what I can see all they need is to
have the catalog set back in once deserialized?
The loadable model could do this...

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

4

Andrea Aime ha scritto:

Works for me, we just have a handful of these cases, so I guess
we can create reusable loadable/detachable models that know
how to re-instate the lost attribute programmatically on reload?
The candidates would be ResourceInfo and subclasses, by
extension LayerInfo (since it holds a ResourceInfo), and
AttributeTypeInfo? From what I can see all they need is to
have the catalog set back in once deserialized?
The loadable model could do this...

Drawing some parallel with the way Hibernate works, what
about a:
Catalog.attach(Info info)
that does reconnect the impl with the catalog after it
has been deserialized. This has the advantage of not having
the UI code explicitly know about what needs to be done
and to make it stay away from the *Impl classes.

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

5

Andrea Aime wrote:

Andrea Aime ha scritto:

Works for me, we just have a handful of these cases, so I guess
we can create reusable loadable/detachable models that know
how to re-instate the lost attribute programmatically on reload?
The candidates would be ResourceInfo and subclasses, by
extension LayerInfo (since it holds a ResourceInfo), and
AttributeTypeInfo? From what I can see all they need is to
have the catalog set back in once deserialized?
The loadable model could do this...

Drawing some parallel with the way Hibernate works, what
about a:
Catalog.attach(Info info)
that does reconnect the impl with the catalog after it
has been deserialized. This has the advantage of not having
the UI code explicitly know about what needs to be done
and to make it stay away from the *Impl classes.

Hmmm... I am not against it but I want to be sure we are not adding a method to the catalog interface just to get around an implementation detail. If we did have a hibernate catalog implementation, would a similar method be necessary? If so I am ok with adding it, if not I would say perhaps add it to the CatalogBuilder for now?

Cheers
Andrea

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

6

Andrea Aime wrote:

Justin Deoliveira ha scritto:

Andrea Aime wrote:

Hi,
I'm having some troubles with the catalog objects I'd like
to discuss.

There are a few catalog objects that do require some access
to GT2 provided information. For example, FeatureTypeInfo
can return a FeatureType, AttributeTypeInfo an AttributeDescriptor.
The way things are done now, that information provided
by some external entity during the object construction.

Which works fine only as long as the object is serialized
and deserialized... which happens when those objects are
used within Wicket models. Now, for pure editing a form
can be backed by a loadable/detachable model that will
grab again the same FeatureTypeInfo from the catalog,
it's more work, but it's doable.

Question, I thought we abandoned using straight serialization for catalog objects and instead adopted loadable detachable models, or is this just in some cases?

In some cases. You cannot use a loadable/detachable model
if there is nothing to detach, in particular, you cannot
detach a catalog object that has not been saved 'cause
there is nothing to reload from the catalog.
In this case, you're basically forced into saving the
object itself (or not?)

Right, I guess my question was that for all objects that have already been added to the catalog, there should be no need to serialize? And a loadable detachable model should be used?

2) Mark a few properties as unsafe to use in the UI,
    and build models that know how to handle them?
Let me know

I don't think I quite understand option 1, but I think I prefer option 2, with perhaps a spin:

a) omit properties that require the external resources, making them available only on an edit, or:

b) if the property is necessary on the new form, create a model that loads it "manually", ie not through the feature type. This is more or less what the old stuff did to get around this i believe

Works for me, we just have a handful of these cases, so I guess
we can create reusable loadable/detachable models that know
how to re-instate the lost attribute programmatically on reload?
The candidates would be ResourceInfo and subclasses, by
extension LayerInfo (since it holds a ResourceInfo), and
AttributeTypeInfo? From what I can see all they need is to
have the catalog set back in once deserialized?
The loadable model could do this...

Sounds good to me.

Cheers
Andrea

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

7

Justin Deoliveira ha scritto:

In some cases. You cannot use a loadable/detachable model
if there is nothing to detach, in particular, you cannot
detach a catalog object that has not been saved 'cause
there is nothing to reload from the catalog.
In this case, you're basically forced into saving the
object itself (or not?)

Right, I guess my question was that for all objects that have already been added to the catalog, there should be no need to serialize? And a loadable detachable model should be used?

Correct.
Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

8

Justin Deoliveira ha scritto:

Drawing some parallel with the way Hibernate works, what
about a:
Catalog.attach(Info info)
that does reconnect the impl with the catalog after it
has been deserialized. This has the advantage of not having
the UI code explicitly know about what needs to be done
and to make it stay away from the *Impl classes.

Hmmm... I am not against it but I want to be sure we are not adding a method to the catalog interface just to get around an implementation detail. If we did have a hibernate catalog implementation, would a similar method be necessary?

Well, it is an implementation details, those are serializable classes
that have fields that do not survive a serialization cycle, that's not
normal, it's something that one has to document.
So, it's an implementation detail now, if you document it in the
javadoc, it's no more.

We can also change those classes so that they get back the catalog during de-serialization, adding a readObject method that first
calls the super, and then sets the catalog by using
GeoServerExtensions to reach to it.

Anwyasy, to get back to the point, the wicket serialization occurs
in memory, has nothing to do with the hibernate long term one,
so the two are orthogonal, a hibernate backed catalog would
have the same problem.

So what should it be, Catalog.attach(Info) or we do try a
reattach on the fly during deserialization?

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

9

Andrea Aime wrote:

Justin Deoliveira ha scritto:

Drawing some parallel with the way Hibernate works, what
about a:
Catalog.attach(Info info)
that does reconnect the impl with the catalog after it
has been deserialized. This has the advantage of not having
the UI code explicitly know about what needs to be done
and to make it stay away from the *Impl classes.

Hmmm... I am not against it but I want to be sure we are not adding a method to the catalog interface just to get around an implementation detail. If we did have a hibernate catalog implementation, would a similar method be necessary?

Well, it is an implementation details, those are serializable classes
that have fields that do not survive a serialization cycle, that's not
normal, it's something that one has to document.
So, it's an implementation detail now, if you document it in the
javadoc, it's no more.

My point is that I want to avoid polluting the Catalog interface with methods that only apply to the in memory implementation, trying to keep the interface clean and resist the temptation of just adding methods as needed. This is what happened more or less to the old catalog code, and you know where it left us :slight_smile:

We can also change those classes so that they get back the catalog during de-serialization, adding a readObject method that first
calls the super, and then sets the catalog by using
GeoServerExtensions to reach to it.

I would like to avoid adding any specific java serialization to those classes... it adds a quite a bit of complexity.

Anwyasy, to get back to the point, the wicket serialization occurs
in memory, has nothing to do with the hibernate long term one,
so the two are orthogonal, a hibernate backed catalog would
have the same problem.

OK, so lets add the method then. Although Catalog.attach(Info) will not really do it since Info applies to configuration objects as well. The pattern in the catalog as of now is to have a method for each type of object, look at add(),save(),remove(), etc..., so:

attach(StoreInfo)
attach(ResourceInfo)

etc...

The reason is because we did not have a root object. We could add a CatalogInfo root object for all catalog objects but i would like to keep the interface methods consistent for now. So i would prefer we either:

1) add attach() methods for each of the type of object, this means 8 methods.

2) add the method to method to CatalogBuilder for now. And perhaps refactor the Catalog interface a bit to use a root Catalog interface.

So what should it be, Catalog.attach(Info) or we do try a
reattach on the fly during deserialization?

Cheers
Andrea

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