Excellent - thanks Ben.
Michael
On 21 September 2010 16:47, Ben Caradoc-Davies
wrote:
> Michael, this should be fixed now (at a small cost in performance).
>
--
Start uncovering the many advantages of virtual appliances
Michael, this should be fixed now (at a small cost in performance).
On 16/09/10 15:49, Michael Bedward wrote:
> Hi Ben and all,
>
> I also struck this same error when I updated and built trunk for the
> first time in several months a couple of days ago.
>
> My first thought was: "Oh no, I've forgo
On 21/09/10 12:05, Jody Garnett wrote:
I understand the problem with using null to represent two cases; can
you check the filter and xpath specifications to see how they handle
this problem? Do they produce an error; or return an empty result? The
answer may inform what we do here; perhaps they
Resource leak in app-schema vocab handling
--
Key: GEOT-3271
URL: http://jira.codehaus.org/browse/GEOT-3271
Project: GeoTools
Issue Type: Bug
Components: data app-schema
Affects Versions:
I understand the problem with using null to represent two cases; can you check
the filter and xpath specifications to see how they handle this problem? Do
they produce an error; or return an empty result? The answer may inform what we
do here; perhaps they have thought of a good way to be clear?
Please keep discussion on the list (you will need to repeat yourself)
On 21/09/2010, at 12:51 PM, Niels wrote:
>
> The problem with separating 'canExecute' from 'execute' is that it wouldn't
> solve the performance issue. To test whether a x-path can be evaluated, the
> only way is often to ac
Thanks Jody - that's very nice of you. Look forward to catching up in
the near future (though I've got a great deal of "remembering" to do
to get back to being useful).
Michael
On 21 September 2010 12:13, Jody Garnett wrote:
> I was reading the user list to see if any questions had gone un answ
The problem with separating 'canExecute' from 'execute' is that it
wouldn't solve the performance issue. To test whether a x-path can be
evaluated, the only way is often to actually try to evaluate it, which
would mean you would be doing the same thing twice if they are in
separate methods. The
I was reading the user list to see if any questions had gone un answered for
over a week; and would love to welcome Micheal back (you have indeed been
missed).
I will be online on and off for the next while myself; but I look forward to
catching up and going over some of the documentation ideas
What did you think of the idea of performing two tests (in order to maintain
performance).
So my performance question may be handled with an extra method:
1. short list property accessors that think they can handle the xpath
expresison using canHandle (this should be a test just to see if the x
I think it would be a good idea to make it optional and still throw a
null value when this particular option is selected "off", like I first
suggested. Question is only, at which point in time and in which manner
this option is selected. Is it something that should be left completely
to the use
Thanks for taking the discussion to the email list Justin; I did warn the patch
author that discussion needed to be public (and would have to wait until after
foss4g).
The one thing I like about the suggestion is not hard coding the jxpath case as
a fall back position.
The concerns I had were:
Hi all,
Recently this patch has been proposed:
http://jira.codehaus.org/browse/GEOT-3066
And this issue was discussed in detail on the mailing list some time ago in
this thread:
http://osgeo-org.1803224.n2.nabble.com/evaluating-invalid-attribute-names-td5489979.html
Apologies for not weighin
So refractions looks like they failed to register their domain name; I have
gotten many private email from those making use of the old maven repository
when working with old versions of geotools.
Can we confirm that the osgeo maven repository is a straight migration?
I can see copies of geoTool
Use name to class mappings before int to class mappings when creating a feature
type
Key: GEOT-3270
URL: http://jira.codehaus.org/browse/GEOT-3270
Project: GeoTools
15 matches
Mail list logo
