GeoServer no AppEngine? Ainda não.

Desde que foi lançado o runtime em Java do AppEngine, que tem havido curiosidade em averiguar as possibilidades desse runtime no que diz respeito à componente spatial, geolocation, gis,..whatever!

O começo foi promissor com várias casos de estudo utilizando a Java Topology Suite (biblioteca de referência, com suporte a todos os tipos de geometrias definidos na especificação OGC Simple Features for SQL), como por exemplo, Java Topology Suite + Google App Engine + Restlet (test) (ainda em 2009) ou App Engine + Java Topology Suite (já em 2010).

Havia também um post do Sean Gillies, também de 2009, mas o link está quebrado,... mas o paciente-zero foi sem dúvida o projecto giscloud, agora arquivado no Google Code Archive.

Relativamente a transformação de coordenadas, a prática corrente era utilizar a Java Map Projection Library, mas com as classes AWT removidas e subsituídas por outras compatíveis, por exemplo, sempre que era utilizado Point2D, ou Rectangle2D. Semelhante ao que fazemos em Android, também por ausência de supporte a AWT, com a javaproj-1.0.6-noawt.jar.

Em 2013, com o Java 7 no AppEngine a sair definitivamente da fase beta, o panorama não se modificou substancialmente. O OpenMap era, e é, overkill, para andar a fazer grandes modificações, e o Geoserver ... nem pensar nisso seria boa ideia. Restava fazer modificações a pequenas bibliotecas como o projecto SimpleMapServer , com supporte a WMS 1.1.0 e 1.3.0., ou então, utilizar bibliotecas para objectivos específicos como a Java ESRI Shape File Reader.

Finalmente, em 2018, com o aparecimento da segunda geração do ambiente standard (OpenJDK 8), e com o aparecimento do ambiente flexível, a esperança de correr o GeoServer no AppEngine rejuvenesceu, mas mais no segundo caso do que no primeiro... ainda para mais porque começaram a pedir o cartão de crédito logo à cabeça, em ambos os casos.

Relativamente ao ambiente standard de segunda geração, deixou de haver uma whitelist de classes do JRE, como há/havia na primeira geração (JRE 7). Também passou a ser possível escrever numa pasta tmp, se bem que os ficheiros escritos nessa pasta irão consumir memória alocada à instância que está a ser utilizada (no GAE, uma instância tem, por defeito, um máx. de 128 MB, podendo o máx. ser aumentado até 1024 MB). Para além disso, os ficheiros escritos na tmp só estarão disponíveis para a instância que os criou, e apenas durante o ciclo de vida dessa instância específica.

Ora, apesar de não haver restrições relativamente à utilização de todas as classes do JRE 8, continuam a haver restrições de escrita persistente na file system. Basta apenas pensar em todos aqueles ficheiros de configuração em XML do GeoServer, para perceber que o GeoServer está quase sempre a escrever no disco.

Relativamente ao ambiente flexível, apesar de uma aplicação correr num contentor Docker numa máquina virtual (VM) do Compute Engine, esssa VM é reiniciada pelo menos uma vez por semana, logo, lá se vai a persistência.

Mais, o GeoServer é bastante exigente: além de requerer total acesso ao filesystem, tem que ser disponibilizada reflexão (o que não acontece neste caso), haver total acesso ao JDK, e ao ambiente de instalação, o que não é garantido que aconteça no ambiente flexível, pelo menos sem modificações de fundo ao código-fonte do GeoServer. Enfim, tem quase os requesitos de uma aplicação desktop. Experimentei e não consegui, e olhando para as listas de mail do GeoServer, também niguém conseguiu. 

Conclusão: é preferível tentar instalar o GeoServer sobre Jetty numa VM a correr directamente no Compute Engine, ou alternativamente, como já se faz há bastante tempo: instalar uma imagem na EC2 - Amazon Elastic Compute Cloud.