Hello,
I think this is a misunderstanding. I did not intend my email as a
complaint or criticism (and especially not to make myself "feel better",
I don't see it that way at all). It was merely intended as an entirely
neutral issue report, like "hey, I found this thing that seemed to have
slipped in to our project that is something for all of us to look at and
think about".
Perhaps "dodgy" was a poor word choice, but all I meant with that
particular sentence was "despite the fact that this isn't causing any
major issues for anyone, it is still a potential loophole and a
situation we should maybe consider improving /either way/". By no means
I was pointing the finger at a particular person(s), I think these
things just happen in a project like ours and I wanted to report it.
That is my honest opinion about it, and that is honestly all that what
was on my mind when I wrote that email.
And yes, I am absolutely more than willing to think along for solutions.
But I didn't have any solutions yet and I felt I needed more information
first, or to study it better, and I thought I'd report it in the
meantime as a open question, invite some brainstorming (as Ben did).
Sometimes other people know things of the top of their heads that they
can respond immediately that saves me a lot of time finding out, so that
is why I send an email before I have a solution. I guess that I should
have written more specific questions in my email rather than ending with
the "dodgy" comment. I do apologise for my poor communication in that
regard, which can be explained by the fact that I wrote it at the end of
my workday (next time, I'll keep it for the beginning of the next and
take the time to ask specific questions). I hope that clears it up.
I do like Ben's suggestions, but of course he is looking at the broader
picture, and particularly from the geotools side. I think any way we can
get rid of static code in geotools would be an improvement.
I have another question though - why is geoserver doing this thing in
GeoServerInitStartupListener? I'm not just asking about the place it is
doing, why is it doing this at all? What was the original idea behind it
and does it still count? I think ImageWorker is on the classpath of
geoserver in any case, so whether it does its own JAI initialisation
before or after ImageWorker, it seems pointless. Or am I wrong?
Kind Regards
Niels
On 12/10/2016 10:48 AM, Andrea Aime wrote:
On Fri, Dec 9, 2016 at 10:19 PM, Ben Caradoc-Davies <b...@transient.nz
<mailto:b...@transient.nz>> wrote:
I think this was a fair comment.
Our community provided a guideline as to what constructive criticism
is, that is not, it's simply criticism (without the constructive part).
The voting guidelines for anything are clear, one can vote -1 but only
providing alternative paths, while this is of course just a random
discussion
the expected approach would be the same, simply venting out criticism
does not help anybody, besides maybe make the
one writing the mail feel better.
I can understand the frustration of someone that did not put the
GeoServerInitStartupListener
as the very first thing running at JVM startup, forgetting or being
unable to do so is going to cause a lot of frustrating debugging (not
just for JAI
but for other aspects as well), however simple complaints are of no
help to anyone.
Andrea, I would appreciate your view on whether GeoTools could
benefit from some sort of configuration API. I know little about
JAI and JAIExt, but could a configuration API be used to inject
some sort of manager into GeoTools? Or do dependencies and cycles
mean we will end up reinventing Spring?
I don't have a view on this problem, haven't been bit by it
significantly and/or when it happened, I could only blame myself
and did not have resource to propose an actual improvement along with
the resources to implement it
(typical case, forgetting to set the axis order hints right on startup).
Just an observation, initialization of JAI is an issue of itself,
something like setting up the registry needs to be done
at startup, very first thing, so some control over init order is
necessary there, what provides this control depends on the technology
used to write the application and its context (command line, OSGI,
servlet, aws lambda), but I'm skeptical that is actually a GeoTools
problem to solve (we'd have to marry some specific class wiring
solution).
The highly dynamic nature of JAI (dynamic registry, priorities,
anything swappable at any time, but not without side effects) makes it
hard to deal with, especially today that we have replaced most parts
of it. If we ever get to rewrite it, the new version could
use some lessons learned to avoid some of these issues (e.g., it could
disallow changing the registry past a certain init point).
Regards
Andrea
--
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate.
Il loro utilizzo è consentito esclusivamente al destinatario del
messaggio, per le finalità indicate nel messaggio stesso. Qualora
riceviate questo messaggio senza esserne il destinatario, Vi preghiamo
cortesemente di darcene notizia via e-mail e di procedere alla
distruzione del messaggio stesso, cancellandolo dal Vostro sistema.
Conservare il messaggio stesso, divulgarlo anche in parte,
distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità
diverse, costituisce comportamento contrario ai principi dettati dal
D.Lgs. 196/2003.
The information in this message and/or attachments, is intended solely
for the attention and use of the named addressee(s) and may be
confidential or proprietary in nature or covered by the provisions of
privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New
Data Protection Code).Any use not in accord with its purpose, any
disclosure, reproduction, copying, distribution, or either
dissemination, either whole or partial, is strictly forbidden except
previous formal approval of the named addressee(s). If you are not the
intended recipient, please contact immediately the sender by
telephone, fax or e-mail and delete the information in this message
that has been received in error. The sender does not give any warranty
or accept liability as the content, accuracy or completeness of sent
messages and accepts no responsibility for changes made after they
were sent or for other risks which arise as a result of e-mail
transmission, viruses, etc.
-------------------------------------------------------
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
