[Geoserver-devel] SQL Views: ReadOnlyDataStore vs JDBCDataStore

Hi all,

I use a custom security wrapper which among other things makes workspaces (& therefore datastores) read-only:

public WorkspaceAccessLimits getAccessLimits(Authentication user, WorkspaceInfo workspace) {
// canRead=true, canWrite=false
return new WorkspaceAccessLimits(CatalogMode.HIDE, true, false);
}

Messing with SQL Views recently, I discovered that the Create SQL View link never appeared for a PostGIS datastore. Turns out this is because of the following check:

createSQLViewContainer.setVisible(da instanceof JDBCDataStore);

and da is a ReadOnlyDataStore (DecoratingDataStore) which delegates to the original JDBCDataStore.

It’s not just enough to change that line/view, the SQL Views implementation uses JDBCDataStore everywhere.

Not sure of the best approach here - Andrea’s initial thoughts in IRC were “we’d need a new interface for JDBCDataStore and a ready only wrapper that maintains it”, but he suggested I bring it here first. If this is likely to be a more widespread problem, is it better to start moving away from instanceof to another comparison that checks through wrappers?

Cheers,

Rob :slight_smile:

Koordinates Ltd.
PO Box 1604, Shortland St, Auckland 1140, New Zealand
Phone +64-9-966 0433 Fax +64-9-969 0045
Web http://koordinates.com/

how about your decorator being a dynamic proxy that implements all the
interfaces the decorated object implements, and delegates to the proxy
object method except for the ones you want to override?

/2c
On Mon, Feb 27, 2012 at 5:53 PM, Robert Coup
<robert.coup@anonymised.com> wrote:

Hi all,

I use a custom security wrapper which among other things makes workspaces (&
therefore datastores) read-only:

public WorkspaceAccessLimits getAccessLimits\(Authentication user,

WorkspaceInfo workspace) {
// canRead=true, canWrite=false
return new WorkspaceAccessLimits(CatalogMode.HIDE, true, false);
}

Messing with SQL Views recently, I discovered that the Create SQL View link
never appeared for a PostGIS datastore. Turns out this is because of the
following check:

createSQLViewContainer\.setVisible\(da instanceof JDBCDataStore\);

and da is a ReadOnlyDataStore (DecoratingDataStore) which delegates to the
original JDBCDataStore.

It's not just enough to change that line/view, the SQL Views implementation
uses JDBCDataStore everywhere.

Not sure of the best approach here - Andrea's initial thoughts in IRC were
"we'd need a new interface for JDBCDataStore and a ready only wrapper that
maintains it", but he suggested I bring it here first. If this is likely to
be a more widespread problem, is it better to start moving away from
instanceof to another comparison that checks through wrappers?

Cheers,

Rob :slight_smile:
--
Koordinates Ltd.
PO Box 1604, Shortland St, Auckland 1140, New Zealand
Phone +64-9-966 0433 Fax +64-9-969 0045
Web http://koordinates.com/

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

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

On Mon, Mar 5, 2012 at 5:39 PM, Gabriel Roldan <groldan@anonymised.com…> wrote:

how about your decorator being a dynamic proxy that implements all the
interfaces the decorated object implements, and delegates to the proxy
object method except for the ones you want to override?

That was my first thought as well, but there are catches:

  • JDBCDataStore is not an interface, so java own dynamic proxies are game over
  • JDBCDataStore is a final class, I believe that also kills any approach using
    bytecode engineered proxies

If we have a IJDBCDataStore (sorry for the ugly name) that is a mixin interface,
listing all the methods that a JDBCDataStore can have, then I guess we can
following the first approach.

I was hoping Justin would chime in, I know the topic of macking JDBCDataStore
non final was raised before, and he did not like the idea

Cheers
Andrea

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf


On Mon, Mar 5, 2012 at 9:50 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Mon, Mar 5, 2012 at 5:39 PM, Gabriel Roldan <groldan@anonymised.com> wrote:

how about your decorator being a dynamic proxy that implements all the
interfaces the decorated object implements, and delegates to the proxy
object method except for the ones you want to override?

That was my first thought as well, but there are catches:

  • JDBCDataStore is not an interface, so java own dynamic proxies are game over
  • JDBCDataStore is a final class, I believe that also kills any approach using
    bytecode engineered proxies

If we have a IJDBCDataStore (sorry for the ugly name) that is a mixin interface,
listing all the methods that a JDBCDataStore can have, then I guess we can
following the first approach.

I was hoping Justin would chime in, I know the topic of macking JDBCDataStore
non final was raised before, and he did not like the idea

Indeed, this was done pretty explicitly due to the mess of subclassing that was the old jdbc datastores. We wanted to avoid subclassing at all cost and instead use the dialog for all the customization. That said, I can see how making the class final is limiting.

I would be ok with making JDBCDataStore an interface, or perhaps factoring out a new interface like IJDBCDataStore or something, as long as we keep the class final.

Cheers
Andrea

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf



Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2


Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


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