Well, apart from the Query tests Jody was talking about the patch is
pretty much ready, me thinks.
But in terms of voting that is another question. Ben is on leave at the
moment.
On 12/01/11 22:54, Justin Deoliveira wrote:
Just to chime in here guys it is getting pretty close to the time we
need to decide what to do as my original plan was to release end of
day Thursday. Three options are:
1) Niels gets work in by Thursday and we release as planned
2) Niels does not get work in and we release anyway
3) We postpone the release until Niels work is in
Please advise how we should proceed.
On Wed, Jan 12, 2011 at 6:30 AM, Jody Garnett <[email protected]
<mailto:[email protected]>> wrote:
I am catching up with the program; what I was worried about did
not actually occur in the code.
Hints are used as part of the configuration of a factory; and
there are mechanisms in place to make sure two factories
configured the same way - do not occur. So when you ask the
FactoryRegistery for a factory with a specific set of hints it
will either give you the matching factory; or create a new one and
remember it for next time.
So I was getting worried about using NamespaceSupport in this
manner; as NamespaceSupport is pretty specific - and not really a
very good value object (ie we don't even know if it implements
"equals" and is suitable for use in a factory registery as
described above).
Turns out that the NamespaceSupport is only passed in during
evaluation; indeed we could of just used a normal java.util.Map
and we would of been just as happy.
Jody
On 12/01/2011, at 11:20 PM, <[email protected]>
<[email protected]> wrote:
> The problem is that then the API of PropertyAccessor and
PropertyAccessorFactory need to be changed too.
> Because the namespace is passed on to them through the hints. If
we don't use the hints at all anymore
> (not even for communication between AttributeExpressionImpl and
PropertyAccessors), we need to add extra parameters in the API to
pass on the NamespaceSupport separately....
>
> Thought I filled in Javadoc as good as possible, might have
forgotten here or there, Sorry.
> ________________________________________
> From: Jody Garnett [[email protected]
<mailto:[email protected]>]
> Sent: Wednesday, January 12, 2011 6:24 PM
> To: Charlier, Niels (CESRE, Kensington)
> Cc: [email protected]
<mailto:[email protected]>
> Subject: Re: [Geotools-devel] Query and CommonFactory finder (ie
beyond namespace 2)
>
> Thanks Niels; reviewing now.
>
> I noticed in PropertyAccessorFactory ...
>
> public static final Key NAMESPACE_CONTEXT = new
Hints.Key(org.xml.sax.helpers.NamespaceSupport.class);
>
> I am a bit worried about funnelling a NamespaceSupport into
different factories as a Hint; I would like to check where this is
used.
>
> Part of why we brought gt-opengis interfaces into the library
was so you could update the FilterFactory2 - just so a hint was
not used (and the factory would not be stateful).
> Can we change AttributeExpressionImpl to accept a
NamespaceSupport explicitly rather than passing it in as part of
the hints?
>
> Other than that (because we are defining new api) we need to
fill in the javadocs (or I will feel guilty making Micheal Bedward
work too hard).
>
> Jody
>
>
> On 12/01/2011, at 7:59 PM, Niels wrote:
>
> I uploaded a patch... If it can be approved before the new
release, it would be nice to include it!
>
> thx
> Niels
>
> On 12/01/11 13:01, Jody Garnett wrote:
> Have a go at your patch now; I can review when you have it ready.
>
> Jody
>
> On 12/01/2011, at 12:12 PM, Niels wrote:
>
> Thanks, Jody! That's great.
>
> On 11/01/11 20:27, Jody Garnett wrote:
>
> Okay I was able to move CommonFactoryFinder (and a couple of
others) over to gt-api.
>
> See patch http://jira.codehaus.org/browse/GEOT-3374 for details.
>
> Jody
>
> On 11/01/2011, at 6:58 PM, Jody Garnett wrote:
>
>
>
> Okay tried out your idea Gabriel.
>
> There are actually two factory finders in play:
> - BasicFactories - used by the geometry library implementations;
never hooked up to gt-referencing (and should be used by
gt-referencing when creating direct positions)
> - CommonFactoryFinder
>
> The superclass you mentioned, FactoryFinder, is actually abstract.
>
> I did try a couple of things:
> - moving to gt-metadata; failed as the code references
ReferencingFactoryFinder (probably not that big a deal as we could
just reverse the relationship)
> - moving to gt-referencing; failed as CommonFactory finder
references FeatureCollection which is part of gt-api and not an
gt-opengis interface
>
> I am going to go away and think for a bit.
> Jody
>
> On 11/01/2011, at 3:05 PM, Jody Garnett wrote:
>
>
>
> A very good idea Gabriel,
>
> I mentioned this on the other email thread but I have an
alternative to consider?
>
> I would like to collect all the factory finder stuff into the
GeoTools class; resulting in more readable code. I think we can do
this as the factory lookup code does not depend on any specific
implementation?
>
> Cheers,
> Jody
>
> On 11/01/2011, at 2:59 PM, Gabriel Roldán wrote:
>
>
>
> On Tue, 2011-01-11 at 13:30 +1000, Jody Garnett wrote:
>
>
> The namespace 2 discussion has been productive (introducing of
gt-opengis, creation of two proposals) but is now stuck...
>
> The Query interface would like to work with PropertyName to
capture a list of xpath expressions to be obtained via the Query.
To do a nice job of this it would be good to have access to a
FilterFactory (by way of CommonFactoryFinder).
>
> Why is this an issue?
> - Query is in gt-api
> - CommonFactoryFinder is in gt-main
>
> Any suggestions?
>
>
> not sure it'll work, but FactoryFinder is in gt-metadata, so
Query could
> just use that one provided the lookup method is refactored into
> FactoryFinder:
>
> public class FactoryFinder{
>
> public static Object lookup(Class category, Hints hints,
Hints.Key key)
> {
> hints = mergeSystemHints(hints);
> ....
> }
>
>
>
>
> Jody
>
------------------------------------------------------------------------------
> Gaining the trust of online customers is vital for the success
of any company
> that requires sensitive data to be transmitted over the Web.
Learn how to
> best implement a security strategy that keeps consumers'
information secure
> and instills the confidence they need to proceed with transactions.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Geotools-devel mailing list
> [email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
> --
> Gabriel Roldan
> [email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>
> Expert service straight from the developers
>
>
>
>
------------------------------------------------------------------------------
> Gaining the trust of online customers is vital for the success
of any company
> that requires sensitive data to be transmitted over the Web.
Learn how to
> best implement a security strategy that keeps consumers'
information secure
> and instills the confidence they need to proceed with transactions.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Geotools-devel mailing list
> [email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
>
> --
> Niels Charlier
>
> Software Engineer
> CSIRO Earth Science and Resource Engineering
> Phone: +61 8 6436 8914
>
> Australian Resources Research Centre
> 26 Dick Perry Avenue, Kensington WA 6151
>
------------------------------------------------------------------------------
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them.
Understand
> malware threats, the impact they can have on your business, and
how you
> can protect your company and customers by using code signing.
>
http://p.sf.net/sfu/oracle-sfdevnl_______________________________________________
> Geotools-devel mailing list
> [email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
>
> --
> Niels Charlier
>
> Software Engineer
> CSIRO Earth Science and Resource Engineering
> Phone: +61 8 6436 8914
>
> Australian Resources Research Centre
> 26 Dick Perry Avenue, Kensington WA 6151
>
------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and
how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Geotools-devel mailing list
[email protected]
<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/geotools-devel
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
--
*Niels Charlier*
Software Engineer
CSIRO Earth Science and Resource Engineering
Phone: +61 8 6436 8914
Australian Resources Research Centre
26 Dick Perry Avenue, Kensington WA 6151
------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
