I have SLD stylesheet that uses Wingdings font as shown here:
<sld:WellKnownName>ttf://Wingdings#0xE0</sld:WellKnownName>
<sld:Fill>
<sld:CssParameter name="fill">#0000FF</sld:CssParameter>
<sld:CssParameter name="fill-opacity">0.5</sld:CssParameter>
</sld:Fill>
But below error is thrown by Geoserver:
Caused by: java.lang.IllegalArgumentException: The specified mark ttf://Wingdings#0xE0 was not found!
at org.geotools.renderer.style.SLDStyleFactory.createMarkStyle(SLDStyleFactory.java:721)
at org.geotools.renderer.style.SLDStyleFactory.createPointStyle(SLDStyleFactory.java:684)
at org.geotools.renderer.style.SLDStyleFactory.getGraphicStroke(SLDStyleFactory.java:1017)
at org.geotools.renderer.style.SLDStyleFactory.createLineStyle(SLDStyleFactory.java:516)
at org.geotools.renderer.style.SLDStyleFactory.createStyleInternal(SLDStyleFactory.java:383)
at org.geotools.renderer.style.SLDStyleFactory.createStyle(SLDStyleFactory.java:333)
at org.geotools.renderer.style.SLDStyleFactory.createStyle(SLDStyleFactory.java:296)
at org.geotools.renderer.lite.StreamingRenderer.processSymbolizers(StreamingRenderer.java:2608)
at org.geotools.renderer.lite.StreamingRenderer.processFeature(StreamingRenderer.java:2490)
at org.geotools.renderer.lite.StreamingRenderer.drawPlain(StreamingRenderer.java:2325)
I tried to copy Wingding.ttf to geoserver_data /styles folder where my SLD style also lives but it does not work and throws exception that it does not support the font. My application has stopped working on ubuntu server but works on mac osx system. How to solve this issue?
Geoserver version is 2.13
Related
So I deployed a build that runs perfectly on my windows machine to a Linux box earlier this morning and when I tried to start the service I got the error below.
Caused by: java.lang.IllegalStateException: AutoConfigure cycle detected between org.springframework.boot.autoconfigure.orm.jpa.HibernateJpaAutoConfiguration and org.springframework.boot.autoconfigure.cache.CacheAutoConfiguration
So I copied all of the libs from the target machine to my windows machine and ran the application from a windows command prompt. The application started fine.
So I eventually remote debugged the application and came up with a very interesting issue that has got my head scratching.
But before I went further I switched on -verbose to make sure the class in question was being loaded from the same jar in both windows and linux.
[Loaded org.springframework.boot.autoconfigure.cache.CacheAutoConfiguration from file:/apps/IRDrsudbld/<project structure>/lib/spring-boot-autoconfigure-1.5.8.RELEASE.jar]
And it is.
So when I debug in linux and look at the metadata for the two classes
this = {AutoConfigurationSorter$AutoConfigurationClass#3645}
className = "org.springframework.boot.autoconfigure.cache.CacheAutoConfiguration"
metadataReaderFactory = {ConcurrentReferenceCachingMetadataReaderFactory#3637}
autoConfigurationMetadata = {AutoConfigurationMetadataLoader$PropertiesAutoConfigurationMetadata#3611}
It states the following
"org.springframework.boot.autoconfigure.cache.CacheAutoConfiguration.AutoConfigureBefore" -> "org.springframework.boot.autoconfigure.orm.jpa.HibernateJpaAutoConfiguration"
"org.springframework.boot.autoconfigure.cache.CacheAutoConfiguration.AutoConfigureAfter" -> "org.springframework.boot.autoconfigure.data.couchbase.CouchbaseDataAutoConfiguration,
org.springframework.boot.autoconfigure.hazelcast.HazelcastAutoConfiguration,
org.springframework.boot.autoconfigure.orm.jpa.HibernateJpaAutoConfiguration,
org.springframework.boot.autoconfigure.data.redis.RedisAutoConfiguration"
But the line in bold is completely wrong as the 1.5.8 source code has the annotations below.
#Configuration
#ConditionalOnClass({CacheManager.class})
#ConditionalOnBean({CacheAspectSupport.class})
#ConditionalOnMissingBean(value = {CacheManager.class},name = {"cacheResolver"})
#EnableConfigurationProperties({CacheProperties.class})
#AutoConfigureBefore({HibernateJpaAutoConfiguration.class})
#AutoConfigureAfter({CouchbaseAutoConfiguration.class, HazelcastAutoConfiguration.class,
RedisAutoConfiguration.class})
#Import({CacheAutoConfiguration.CacheConfigurationImportSelector.class})
public class CacheAutoConfiguration {
Has anyone seen an issue like this before as I am completely mystified as to what is happening here.
Thanks
After debugging the code it appears that one of the internal shaded jar files contains a spring-autoconfigure-metadata.properties which is for spring boot 2. When the application is executed on linux this jar file is loaded after the spring boot autoconfigure one and replaces the
org.springframework.boot.autoconfigure.cache.CacheAutoConfiguration.AutoConfigureAfter
Property with one that is not valid for the spring boot version in my application.
At least I have found out what the problem is.
I cannot seem to find anything related to my problem in stack overflow. I've downloaded jdk 13.0 and elasticsearch 7.4.0.
On cmd setting path to C:\Users\Desktop\download\elasticsearch-7.4.0-windows-x86_64\elasticsearch-7.4.0\bin I execute:
elasticsearch.bat
Which outputs:
OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release.
Exception in thread "main" java.nio.file.InvalidPathException: Illegal char <?> at index 9: C:\Users\???\AppData\Local\Temp\elasticsearch
at java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182)
at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153)
at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77)
at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92)
at java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:229)
at org.elasticsearch.common.io.PathUtils.get(PathUtils.java:60)
at org.elasticsearch.env.Environment.<init>(Environment.java:95)
at org.elasticsearch.node.InternalSettingsPreparer.prepareEnvironment(InternalSettingsPreparer.java:69)
at org.elasticsearch.cli.EnvironmentAwareCommand.createEnv(EnvironmentAwareCommand.java:95)
at org.elasticsearch.cli.EnvironmentAwareCommand.execute(EnvironmentAwareCommand.java:86)
at org.elasticsearch.cli.Command.mainWithoutErrorHandling(Command.java:125)
at org.elasticsearch.cli.Command.main(Command.java:90)
at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:115)
at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:92)
I've read https://github.com/elastic/elasticsearch/issues/43911 and people say they've solved it by increasing the ram in kubernetes. I have no knowledge of kubernetes and I'm not using it so I've decided to post this question.
Could someone tell me why running elasticserach.bat is failing?
EDIT : as developer suggested
I've read https://confluence.atlassian.com/doc/setting-the-java_home-variable-in-windows-8895.html and followed the procedure and still gives me same error message.
But my path seems pretty odd compared to the resource I've followed. This is my path:
C:\Users\myname\Desktop\download\jdk-13.0.1_windows-x64_bin\jdk-13.0.1
which gave me same error as before.
I've noticed java.exe is inside bin folder which is inside jdk-13.0.1 so I've tried setting value for system variable as
C:\Users\myname\Desktop\download\jdk-13.0.1_windows-x64_bin\jdk-13.0.1\bin
and now it give me:
"could not find java in JAVA_HOME or bundled at C:\Users\myname\Desktop\download\elasticsearch-7.4.0-windows-x86_64\elasticsearch-7.4.0\jdk"
I clearly see java.exe inside bin folder, why is it saying it cannot find it?
I have built a Cordova-based Windows application. As soon as I add any plugin, the app starts crashing with the exception cordova/windows8/commandProxy not found.
Cordova version: 4.3.0
It seems that cordova/windows8/commandProxy is deprecated in Cordova 4.3.0.
I have replaced this statement in plugin file
require("cordova/windows8/commandProxy")
to
require("cordova/exec/proxy")
and it seems to work.
For example I changed line number 18 in PushPluginProxy.js from
require("cordova/windows8/commandProxy").add("PushPlugin", module.exports);
to
require("cordova/exec/proxy").add("PushPlugin", module.exports);
The name in the string varies depending on the plugin.
Alternatively, you can patch the plugin like in this pull request from the AppVersion plugin i.e.:
Change
require("cordova/windows8/commandProxy").add("AppVersion", AppVersionProxy);
to
cordova.commandProxy.add("AppVersion", AppVersionProxy);
I'm unable to use PAM plugin on SonarQube 5.1 on Debian 8 (64bit).
I did setup according to https://github.com/SonarCommunity/sonar-pam and still getting following error during login:
Java::JavaLang::UnsatisfiedLinkError (no jpam in java.library.path):
java.lang.ClassLoader.loadLibrary(ClassLoader.java:1886)
java.lang.Runtime.loadLibrary0(Runtime.java:849)
java.lang.System.loadLibrary(System.java:1088)
net.sf.jpam.Pam.<clinit>(Pam.java:51)
org.sonar.plugins.pam.PamConfiguration.newInstance(PamConfiguration.java:61)
org.sonar.plugins.pam.PamConfiguration.getPAM(PamConfiguration.java:49)
org.sonar.plugins.pam.PamAuthenticator.authenticate(PamAuthenticator.java:45)
org.sonar.api.security.SecurityRealm$1.doAuthenticate(SecurityRealm.java:60)
Here's setup (sonar is located at /var/lib/sonarqube-5.1):
/var/lib/sonarqube-5.1/lib/JPam-1.1.jar
native libs (64bit and 32bit) have been put to /var/lib/sonarqube-5.1/bin/linux-x86-64/lib/libjpam.so and /var/lib/sonarqube-5.1/bin/linux-x86-32/lib/libjpam.so (just for sure in case sonar was run as 32bit)
All directories leading to native libraries and libraries themselves have +rx access
Any idea what can be causing problem?
I'd print the java.library.path variable. The only thing I can think of is that the jpam lib is in the wrong place or there is an issue with permissions. (Did you check the SonarQube user can actually read that file?)
UPDATE
Check java.library.path in Settings->System Info page
Move jpam lib to one of those paths
I have to display a logo in every page of a generated PDF. Though it works fine in the local system, it throws following exception in the server:
Fatal error: Uncaught exception 'PDFlibException' with message 'Handle parameter or option of type 'image' has bad value 0' in /var/www/dev/subdomains/rfqms/httpdocs/sprintnineteen/system/plugins/dompdf/include/pdflib_adapter.cls.php:664 Stack trace: #0 /var/www/dev/subdomains/rfqms/httpdocs/sprintnineteen/system/plugins/dompdf/include/pdflib_adapter.cls.php(664): PDFlib->fit_image(0, 30, 746, 'boxsize={86 43}...') #1 /var/www/dev/subdomains/rfqms/httpdocs/sprintnineteen/system/plugins/dompdf/include/php_evaluator.cls.php(66) : eval()'d code(16): PDFLib_Adapter->image('http://rfqms.de...', 'jpg', 30, 3, 86.4, 43.2) #2 /var/www/dev/subdomains/rfqms/httpdocs/sprintnineteen/system/plugins/dompdf/include/php_evaluator.cls.php(66): eval() #3 /var/www/dev/subdomains/rfqms/httpdocs/sprintnineteen/system/plugins/dompdf/include/php_evaluator.cls.php(70): PHP_Evaluator->evaluate('??//$base_img_u...') #4 /var/www/dev/subdomains/rfqms/httpdocs/sprintnineteen/system/plugins/dompdf/include/renderer.cls.php(180): PHP_Evaluator->render(O in /var/www/dev/subdomains/rfqms/httpdocs/sprintnineteen/system/plugins/dompdf/include/pdflib_adapter.cls.php on line 664
After some analysis I found that in local it uses cpdf_adapter.cls.php for image, where as in server it uses pdflib_adapter.cls.php for image.
I even tried for all the types of images according to:
pdfLib tutorial Version 8.0.2 ---page # 166--- Inline images are only supported for imagetype=ccitt, jpeg, and raw. For other image types the inline option will silently be ignored.
So, what is the problem that leads to this exception?
some additional info:
local PHP Version 5.3.0
server PHP Version 5.2.16
dompdf version 0.5.2
DOMPDF_TEMP_DIR has r/w/e permission
local machine is windows vista
server machine is linux
There was a bug in dompdf at some point related to adding images via PDFLib. I'm not sure if the issue has been addressed yet or not for the upcoming 0.6.0 release. There is a relevant thread on the support group. Take a look at my last post there for information on a work-around if you want to continue using PDFLib.
The other option would be to tell dompdf to use CPDF. In dompdf_config.inc.php set DOMPDF_PDF_BACKEND to "CPDF" instead of "auto" or "PDFLib".