Hello Andrea,
I definitely wouldn't want to move all initialisation code to static, if
anything I'd prefer moving things the other way as Ben suggested.
My question was rather about those specific lines of code (initialising
the OperationRegistry). My assumption was ImageWorker was going to be on
the class path anyway, but you have answered my question by saying that
this is not actually the case.
However, it appears that jai-ext is on the classpath of gs-main in any
case. At least the following small patch could be an improvement that
would prevent the issue we came across without the need for double
initialisation of jai-ext:
https://github.com/geoserver/geoserver/pull/2032/
Does that make sense?
For the rest, I think it is an interesting discussion for the long run
to think of a more structured way to initialise geotools.
Kind Regards
Niels
On 14-12-16 15:55, Andrea Aime wrote:
On Mon, Dec 12, 2016 at 1:58 PM, Niels Charlier <ni...@scitus.be
<mailto:ni...@scitus.be>> wrote:
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?
For most things I believe there is no obvious/simple alternative to
performing certain inits as the very first action while the app starts up.
Let's have a look line by line:
* GeoTools initialization, that needs to be done very first thing to
avoid losing logging and JAI logs,
https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/geoserver/GeoserverInitStartupListener.java#L85
<https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/geoserver/GeoserverInitStartupListener.java#L85>
* Avoid logs on standard error in JAI, also needs to be done first,
or we might get some spurious logs during system init,
https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/geoserver/GeoserverInitStartupListener.java#L88
<https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/geoserver/GeoserverInitStartupListener.java#L88>
* Setting up JAI alternative registry and tile cache, yep, also
needs to be done very first thing, if not you already know what
the consequences are:
https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/geoserver/GeoserverInitStartupListener.java#L121
<https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/geoserver/GeoserverInitStartupListener.java#L121>
Not setting up these two at all will have dire scalability and
runtime consequences, either under high load or in certain
conditions (e.g., highly oversampled requests)
* Forcing axis order, also needs to be done before anything starts
using the CRS factories or the order won't be the expected one,
https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/geoserver/GeoserverInitStartupListener.java#L141
<https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/geoserver/GeoserverInitStartupListener.java#L141>
This could actually be avoided by applying everywhere the same
changes you just proposed in the geopackage module, and that would
be applied in several other places as well, plus changing the axis
order logic in WMS 1.3, in WFS, in the GML encoder, and so on...
doable, not sure anyone is willing to spend days to chase all the
points where this happens, and then discoverer 6 months later that
a few have been missed (not to mention, the effect on plugins that
are not in the GeoTools/GeoServer source trees, those would have
to be updated too).
Anyways, worth pursuing imho, just hard to fund.
* The rest of the inits in that method are also needed to be done
very first thing, but are a bit less obvious to explain. Suffice
it to say that not doing those will have other adverse effects,
either functional, performance or availability related
The JAI initializations should not be moved to the ImageWorker for the
simple reason that not everything uses the ImageWorker, and its
initializations are specific to a few operations... if anything, I'd
move the ImageWorker inits somewhere else instead. However there is no
obvious place at the moment, GeoTools.init would not have the
necessary classes in the classpath.
_Maybe_ a plugin system could be developed to allow per module inits
that would be called as GeoTools.init is called.... still, people
would have to remember to call it.
Not all use cases will need all the inits that GeoServer is
performing, a desktop application will likely not need several of them
(several of the JAI related ones) and under different conditions,
different registries and tile caches (we have done several times in
GeoSolutions to adapt to the specific environment requirements).
Cheers
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 <tel:+39%200584%20962313>
fax: +39 0584 1660272 <tel:+39%200584%20166%200272>
mob: +39 339 8844549 <tel:+39%20339%20884%204549>
http://www.geo-solutions.it
http://twitter.com/geosolutions_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.
-------------------------------------------------------
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
