Re: [Geotools-devel] app-schema / complex features module

[Adam.Brown]

Hi Andrea,

Sorry, I think my previous email might have been a bit misleading: XSDMapping 
is just an @interface whose only dependency is on java.lang.annotation.*. I put 
it in gt-main to keep it next to FeatureWrapper, with which I intend it to be 
used. Both of these files can be moved elsewhere if gt-main isn't appropriate 
for them?

Thanks,


Adam

-Original Message-
From: Caradoc-Davies, Ben (CESRE, Kensington) 
Sent: Wednesday, 14 November 2012 1:51 PM
To: Andrea Aime
Cc: Brown, Adam (CESRE, Kensington); Angreani, Rini (CESRE, Kensington); 
geotools-devel@lists.sourceforge.net
Subject: Re: [Geotools-devel] app-schema / complex features module

On 13/11/12 16:07, Andrea Aime wrote:
> On Tue, Nov 13, 2012 at 6:06 AM,  > wrote:
> The work that I did in ComplexFeature Parsing and building support
> is located at
> https://github.com/Adam-Brown/geotools/tree/gml_client_lib. It
> includes a generic feature builder, a complex feature builder and an
> attribute builder which I put in gt-main. I also added XSDMapping
> and FeatureWrapper to gt-main - the idea of these is to help people
> define strongly-typed classes that they use with the complex feature
> parser.
> Does that mean that main ends up depending on gt-xsd-*? That is 
> something I would not be very happy to see, not everybody needs to 
> deal with EMF/XSD when working on GIS applications.

I believe avoiding this was a pretty strong design goal. Note also that
gt-xsd-gml3 depends on gt-main, so Maven will helpfully choke on any attempt to 
make gt-main depend on gt-xsd-gml3 as it does not support circular 
dependencies.  :-)

Kind regards,

--
Ben Caradoc-Davies  Software Engineer CSIRO Earth 
Science and Resource Engineering Australian Resources Research Centre
--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] app-schema / complex features module

[Ben Caradoc-Davies]

On 13/11/12 16:07, Andrea Aime wrote:
> On Tue, Nov 13, 2012 at 6:06 AM,  > wrote:
> The work that I did in ComplexFeature Parsing and building support
> is located at
> https://github.com/Adam-Brown/geotools/tree/gml_client_lib. It
> includes a generic feature builder, a complex feature builder and an
> attribute builder which I put in gt-main. I also added XSDMapping
> and FeatureWrapper to gt-main - the idea of these is to help people
> define strongly-typed classes that they use with the complex feature
> parser.
> Does that mean that main ends up depending on gt-xsd-*? That is
> something I would not be very happy to see,
> not everybody needs to deal with EMF/XSD when working on GIS applications.

I believe avoiding this was a pretty strong design goal. Note also that 
gt-xsd-gml3 depends on gt-main, so Maven will helpfully choke on any 
attempt to make gt-main depend on gt-xsd-gml3 as it does not support 
circular dependencies.  :-)

Kind regards,

-- 
Ben Caradoc-Davies 
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] plugging in a custom DataSource to jdbc data store

[Justin Deoliveira]

Hi all,

I am experimenting with a way to supply my own customized DataSource
wrapper to a jdbc datastore. Basically my use case is playing with a
connection proxy library like log4jdbc to log some more extended
information about connections, monitor possible connection leaks, etc...

Now, I know that I can pass in a direct DataSource implementation into a
datastore via the JDBCDAtaStoreFactory.DATASOURCE parameter but that isn't
ideal for my case as I want to use this in situations like GeoServer where
data stores are created from serialized connection parameters, and I want
something that will be or less transparent to that process. I looked at the
ConnectionLifecycleListener stuff, which while very nice and gets me part
of what i want, doesn't do it all since i actually need to wrap
connections.

So... looking around I actually see something that fits the bill in the
shape of DataSourceFactorySpi. As far as i can tell though this api isn't
really used at all by the jdbc datastore subsystem, well for creation of a
data source at least. The only usage from jdbc itself seems to be the
UnWrapper interface which is used by oracle to access the native oracle
connection. The api does seem to be used in coverage land by imagemosaic
for creating a jdbc datasource for the tile index (or so i assume).

Basically what I was thinking was something like adding
a DataSourceFactorySpi member to JDBCDataStoreFactory, the default value of
which being a factory that creates a dbcp data source like is done today.
By making the member settable it should be easy enough to specify your own
custom DataSource. It would look something like:

Map connectionParams = ...
JDBCDAtaStoreFactory factory = getFactoryFromParams(connectionParams);
factory.setDataSourceFactory(new MyCustomDataSourceFactory());


Long story short I can think of two approaches (and alternatives very
welcome).

1. Try to utilize DataStoreFactorySpi
2. Roll a more specific interface for this case

I spent some time exploring option (1), but there are a couple of obstacles
with it. The main one is that DataStoreFactorySpi implementations use
different parameters than JDBCDataStoreFactory does. The parameters are
similar, but different enough. For instance the DBCPDataSourceFactory uses
"username"/"password" rather than "user"/"passwd".
The DBCPDataSourceFactory also misses a number of parameters such as
prepared statement pooling options, connection timeout, validation, etc...

I couldn't come up with a great solution for this. I experimented with a
sub interface named DataStoreFactorySpi2 that added the following method:

Map convertDataStoreParameters(Map params, JDBCDataStoreFactory
dataStoreFactory, SQLDialect dialect)


Which basically transformed the dataStore factory parameters to the ones
needed by the data source. This kind of worked but was pretty messy as much
of the data source configuration logic is dependent on the dialect itself,
whether its prepared statement or not, etc... This option also requires
more or less duplicating all the connection parameters from the data store,
etc...

So... (1) is probably doable, but far from trivial and could get messy.


Approach (2) would really just be the simplest thing I can think of.
Basically the interface would be the
JDBCDataStoreFactory.createDataStore(Map, SQLDialect) method factored out
into an interace:

interface JDBCDataSource[Factory|Builder|Creator|WWW] {

  DataSource createDataSource(Map params, SQLDialect dialect);

}


With the default implementation doing exactly what the existing method does
today, and that is return a BasicDataSource, wrapped in the manageable
DBCPDataSource wrapper. An alternative implementation would be used by
the JDBCJNDIDataStoreFactory.


Any thoughts or suggestions?

-Justin

-- 
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Ready for the feature collection cleanup to land?

[Justin Deoliveira]

On Mon, Nov 12, 2012 at 4:31 PM, Jody Garnett wrote:

> Yep. We are ready now ( after your branch is rebased ),  it chose to avoid
> the work week.
>
> Are you okay for Friday afternoon Justin? I can join you on IRC and push
> the button. then it should be done by the time Andrea wakes up and checks
> what happened to rendering performance.
>

Yup, sure i will be around. And in the meantime I will try to merge in the
latest to my branch (i never rebase a public branch until doing a merge
back into a primary branch) .

>
>
>
> --
> Jody Garnett
>
> On 13/11/2012, at 3:19 AM, Justin Deoliveira  wrote:
>
> Great, thanks guys. So if i read the meeting minutes the plan is to pull
> the trigger on this (geoserver + udig) next weekend?
>
> On Mon, Nov 12, 2012 at 7:47 AM, Andrea Aime  > wrote:
>
>> On Mon, Nov 12, 2012 at 1:46 AM, Justin Deoliveira 
>> wrote:
>>
>>>
>>>
>>> On Sat, Nov 10, 2012 at 2:09 AM, Andrea Aime <
>>> andrea.a...@geo-solutions.it> wrote:
>>>
 Hi,
 I was chatting with Jody on IRC and it seems the feature collection
 work on
 the Geotools side is done with a pull request ready to be merged.
 uDig seems to be ready as well, whilst GeoServer wise as far as I
 understand
 we have a branch that Justin made that also works, but no pull request.

>>> I pushed the changes up to my own repo last weekend and was waiting for
>>> a review, specially of the secure feature collection part of the changes.
>>> Perhaps I missed it but never heard back if it looked ok or not.
>>>
>>
>> Ops, sorry Justin, I definitely reviewed the changes and they were ok,
>> believe I've wrote
>> something down too on the pull request but I guess I got distracted and
>> failed to
>> send the message... sorry!
>>
>> Anyways, good to go
>>
>> Cheers
>> Andrea
>>
>>
>> --
>> ==
>> Our support, Your Success! Visit http://opensdi.geo-solutions.it for
>> more information.
>> ==
>>
>> Ing. Andrea Aime
>> @geowolf
>> Technical Lead
>>
>> GeoSolutions S.A.S.
>> Via Poggio alle Viti 1187
>> 55054  Massarosa (LU)
>> Italy
>> phone: +39 0584 962313
>> fax: +39 0584 1660272
>> mob: +39  339 8844549
>>
>> http://www.geo-solutions.it
>> http://twitter.com/geosolutions_it
>>
>> ---
>>
>>
>
>
> --
> Justin Deoliveira
> OpenGeo - http://opengeo.org
> Enterprise support for open source geospatial.
>
>
> --
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_nov
>
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>


-- 
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] app-schema / complex features module

[Andrea Aime]

On Mon, Nov 12, 2012 at 12:35 PM, Niels Charlier  wrote:

> Hi Ben and mailing list,
>
> I would like to propose that some of the stuff in the app-schema module
> gets taken out of the app-schema module, and move either in a new module
> or into an existing module.
>
> The issue I am dealing with now is that I need to use a bunch of stuff
> from app-schema that has to do with complex features in the CSW module,
> but it doesn't actually have anything to do with app-schema itself at
> all (application schema mappings etc).
> In particular
> - Creating complex feature types and features from scratch.
> - Certain parts of the feature type registry, in particular the creation
> of feature types from xsd schemas.
> - The complex feature property accessor, which makes it possible to
> retrieve properties from features with namespace qualified advanced
> x-paths in filters etc...
>
> In my view these things are really something separate from all the rest
> of the stuff that is used to support the application schema mappings
> specifically. Separating these concerns has a number of advantages:
> - A module like CSW can use these features without relying on a whole
> module of which most of the stuff really has nothing to do with it.
> - People can easily implement other implementations of complex feature
> stores or other things that use complex features without having to use
> app-schema.
>

I like the direction, this is very much needed to get complex features
some life outside of the app-schema module

Cheers
Andrea

-- 
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

---
--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] app-schema / complex features module

[Andrea Aime]

On Tue, Nov 13, 2012 at 6:06 AM,  wrote:

> Hi Niels, et al.,
>
> The work that I did in ComplexFeature Parsing and building support is
> located at https://github.com/Adam-Brown/geotools/tree/gml_client_lib. It
> includes a generic feature builder, a complex feature builder and an
> attribute builder which I put in gt-main. I also added XSDMapping and
> FeatureWrapper to gt-main - the idea of these is to help people define
> strongly-typed classes that they use with the complex feature parser.
>

Does that mean that main ends up depending on gt-xsd-*? That is something I
would not be very happy to see,
not everybody needs to deal with EMF/XSD when working on GIS applications.

Cheers
Andrea

-- 
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

---
--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel