On one server, and on my Windows laptop, producing PDFs with this method works fine:
http://www.databasesandlife.com/svg-to-pdf/
But on the other server I get this error:
org.apache.batik.transcoder.TranscoderException: Error while setting up PDFDocumentGraphics2D
Enclosed Exception:
Error while setting up fonts
at org.apache.fop.svg.PDFTranscoder.transcode(PDFTranscoder.java:189)
at org.apache.batik.transcoder.XMLAbstractTranscoder.transcode(Unknown Source)
at org.apache.batik.transcoder.SVGAbstractTranscoder.transcode(Unknown Source)
at org.apache.batik.apps.rasterizer.SVGConverter.transcode(Unknown Source)
at org.apache.batik.apps.rasterizer.SVGConverter.execute(Unknown Source)
I have been Googling and searching for hours, but to no avail. What can I do?
I tried installing the following packages but they didn't help:
sudo apt-get install gsfonts gsfonts-x11 gsfonts-other batik \
libbatik-java libxmlgraphics-commons-java \
libxmlgraphics-commons-java fop sun-java6-fonts
My situation is:
Debian 6.0.3
Sun Java version "1.6.0_26"
JARs: avalon-framework-4.2.0.jar batik-all-1.7.jar commons-io-1.3.1.jar commons-logging-1.0.4.jar fop-0.95.jar log4j-1.2.15.jar xml-apis-ext.jar xmlgraphics-commons-1.3.1.jar
Sincerely it is not a good idea to create such temporary files inside the jetty structure from the Debian package. In case of an update, you may get into troubles. Such a cache directory should be located in /var, like /var/tmp for instance.
According to documentation, FOP is supposed to use the temporary directory in case of failure. Probably your finding deserves a bug report.
Until it is fixed, you should set cache-file option Disabling cache with use-cache is another way but probably with performance impacts.
The approach to solving this problem is in log4j.properties I turned up the level to TRACE.
There I saw the extra log before the TranscoderException that I'd seen previously:
2012-02-28 11:51:24,863 DEBUG: org.apache.fop.fonts.FontCache:
Writing font cache to /usr/share/jetty/.fop/fop-fonts.cache
org.apache.batik.transcoder.TranscoderException:
Error while setting up PDFDocumentGraphics2D
Horray for logs! (And writing a log about what the program is about to do, not just once it has done it, so that if the operation fails, then you know what it was trying to do while it failed.)
On Debian, the Jetty webserver runs under the user jetty and has its home directory at /usr/share/jetty/. However, the jetty user does not have write-access to its own home directory, therefore this ~/.fop directory could not be created.
adrian#10770-02:~$ grep jetty /etc/passwd
jetty:x:107:111::/usr/share/jetty:/bin/false
adrian#10770-02:~$ ls -ld /usr/share/jetty
drwxr-xr-x 7 root root 4096 Feb 28 11:52 /usr/share/jetty/
I don't know whether this is by design, or a bug, but creating this directory so that Jetty could write it...
sudo mkdir -p -m 0777 /usr/share/jetty/.fop
...solved the problem.
Related
Trying to deploy a Play Framework based Application using an ELB container
Recently it seems that AWS made changes to the way ELB works as we've done this before without issue.
The error we currently get is:
2021/12/14 23:00:15.705423 [INFO] Executing instruction: CheckProcfileForJavaApplication
2021/12/14 23:00:15.705468 [ERROR] An error occurred during execution of command [app-deploy] - [CheckProcfileForJavaApplication]. Stop running the command. Error: there is no Procfile and no .jar file at root level of your source bundle
2021/12/14 23:00:15.705474 [INFO] Executing cleanup logic
2021/12/14 23:00:15.705598 [INFO] CommandService Response: {"status":"FAILURE","api_version":"1.0","results":[{"status":"FAILURE","msg":"Engine execution has encountered an error.","returncode":1,"events":[{"msg":"Instance deployment failed. For details, see 'eb-engine.log'.","timestamp":1639522815,"severity":"ERROR"}]}]}
Now of course I wouldn't be here if this was the actual problem
# cd /var/app/staging/server-xxxxxxxxxxx/
# ls -l
total 16
-rw-r--r-- 1 webapp webapp 135 Dec 14 20:39 Procfile
drwxr-xr-x 2 webapp webapp 82 Dec 14 22:21 bin
drwxr-xr-x 2 webapp webapp 113 Dec 14 22:21 conf
drwxr-xr-x 2 webapp webapp 8192 Dec 14 22:21 lib
drwxr-xr-x 3 webapp webapp 17 Dec 14 22:21 share
So Procfile exists
Hmmm is it valid however?
Let's check that out:
# cat Procfile
web: bin/server -v -J-Xms512M -J-Xmx2048m -J-server -Dhttp.port=5000 -Dhttps.port=8443 -Dconfig.resource=application.conf
Looks normal enough -- but does it actually work?
Short answer is yes -- if I copy and paste that command (minus the "web:" prefix of course) system comes up without any issues (ELB still fails to realize that though...)
I've tried a few variants of the command thinking that it might be related to yaml formatting of perhaps a tighter regex ^[A-Za-z0-9_-]+:\s*[^\s].*$ (source: https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/platforms-linux-extend.html)
web: bin/server
web: ./bin/server
web: bin/server
web: ./bin/server
web:bin/server
web:./bin/server
No difference (both worked when manually started without or without the leading ./ btw)
Unsure how I move forward here?
How do we find what the real problem is so that we have fighting chance to fix it?
And yes -- the initial trace above is already the output of eb-engine.log
Using (in case this is relevant)
Coretto Java 11
Play 2.8.8
Scala 2.13.6
SBT 1.5.2
Will answer any relevant queries that help improve this question and any chance of resolving it. Most Google searches I've dug through are related to other environments and are simply a missing Procfile...
I have worked out the following work-around to be able to use a standard (well slightly modified) Play Framework dist directly in an AWS ELB Java container
We start with the typical sbt dist process to create a zip "distribution" file
That file won't work in the format it is currently in (I've been researching and I will be asking specific questions to see if making it work directly might be possible) however it only takes a few small tweaks to get it to work
First Step: Modify Procfile (a file that you manually create and place in the project's dist directory) as follows:
web: chmod 700 bin/server; bin/server -v -J-Xms512M -J-Xmx2048m -J-server -Dpidfile.path=/dev/null -Dhttp.port=5000 -Dconfig.resource=application.conf
Note the chmod 700 bin/server; that was the final secret sauce required to make this work! I was kinda shocked that it did work actually. I did not think that would get past the regex they use to parse the Procfile
As a zip file is permissions agnostic, once I finally got the elb install process to get past that first "missing jar" hurdle I noticed the permissions on bin/server were simply rw. The ec2 instance's /var/log/eb-engine.log did not quite spell that out too clearly, however I confirmed that whenever I manually modified those permissions (on the ec2 instance) and then ran the bin/server command (to verify it) the Play server would start right away (however the elb container still failed to see it as a legitimate process and continued to report it as Status of no data, nor did it allow the load balancer to send it traffic so this "fix" was a real shot in the dark!)
Second step: Unzip that zip file and cd into the directory it created/assigned
cd server-vxxxxxxxxxxxxxx
touch placeholder.jar
The second dab of secret sauce is that the placeholder.jar file is simply a means to satisfy the CheckProcfileForJavaApplication which simply looks for the existence of any file named *.jar in the root of the bundled directory. If that file does not exist then the elb install script stops dead in it's tracks.
Note: You could simply place this empty placeholder.jar file in the Play dist folder if you prefer
Third Step: Create a new zip file elb.zip
zip --exclude share/doc/api/\* -r elb.zip .
Now take elb.zip and upload it to an AWS ELB container and low and behold it (finally) springs to life!
I have a program that uses Sqlite database. It works fine on Windows (exported jar or directly in Eclipse) but when I move it to linux server (plan is to use run it at certain intervals, cron job). I'm exporting it to jar from Eclipse and packing the sqlite-jdbc4-3.8.2-SNAPSHOT.jar with it. Error is this:
/$ /usr/bin/java -jar /home/username/Software.jar /home/username/
java.lang.UnsatisfiedLinkError: /tmp/sqlite-3.8.2-amd64-libsqlitejdbc.so: /tmp/sqlite-3.8.2-amd64-libsqlitejdbc.so: failed to map segment from shared object: Operation not permitted
Exception in thread "main" java.lang.UnsatisfiedLinkError: org.sqlite.core.NativeDB._open(Ljava/lang/String;I)V
at org.sqlite.core.NativeDB._open(Native Method)
at org.sqlite.core.DB.open(DB.java:161)
at org.sqlite.core.CoreConnection.open(CoreConnection.java:145)
at org.sqlite.core.CoreConnection.<init>(CoreConnection.java:66)
at org.sqlite.jdbc3.JDBC3Connection.<init>(JDBC3Connection.java:21)
at org.sqlite.jdbc4.JDBC4Connection.<init>(JDBC4Connection.java:23)
at org.sqlite.SQLiteConnection.<init>(SQLiteConnection.java:44)
at org.sqlite.JDBC.createConnection(JDBC.java:113)
at org.sqlite.JDBC.connect(JDBC.java:87)
at java.sql.DriverManager.getConnection(DriverManager.java:582)
at java.sql.DriverManager.getConnection(DriverManager.java:207)
....
So before you ask, I've made sure that sqlite-3.8.2-amd64-libsqlitejdbc.so in /tmp/ has all permissions (rwxrwxrwx). Still that native library is causing problems. It does get copied in /tmp/ folder though. That being said I totally suck in Linux... and for that reason I'm pretty much clueless what to try next.
What should I do? Switch connector?
EDIT:
Solved the problem by using System.setProperty("java.io.tmpdir", "/home/username/"); Apparently it for some reason couldn't execute the native library from tmp folder... Probably because it was created by root. Also I had to revert back to sqlite-jdbc-3.7.2.jar because the new one crashes on linux.
I had same problem, and I found the solution in this GitHub issue:
JAVA_OPTS=-Djava.io.tmpdir=/path/to/some/other/tmpdir bin/cerebro
Also look at this other SO answer.
I've got a problem with JacORB 3.2 as it seems that it doesn't read the orb.properties file, and especially the ORBInitRef.NameService property.
As stated in the documentation on chapter 3.1, JacORB automatically searches for the orb.properties file in three locations: the "java.home"/lib directory, the "user.home" directory and inside the classpath.
This is the evidence that I'm not totally drunk:
Java command:
System.out.println(System.getProperty("java.home"));
System.out.println(System.getProperty("user.home"));
Output:
/usr/lib/jvm/jdk1.7.0/jre
/home/emanuele
Bash command:
ls /usr/lib/jvm/jdk1.7.0/jre/lib | grep orb.properties ; ls /home/emanuele | grep orb.properties
Output:
jacorb.properties
orb.properties
jacorb.properties
orb.properties
These four .properties file are exactly the same. Please have a look at the URI of the file that contains the reference (IOR) of the NameService:
ORBInitRef.NameService=file:/tmp/CORBA/NS_Ref
The problem is that, when I try to launch the NameService without any parameter (ns) I got these error messages:
giu 05, 2013 9:56:51 PM org.jacorb.naming.NameServer main
SEVERE: unexpected exception
java.io.FileNotFoundException: c:/NS_Ref (No such file or directory)
at java.io.FileOutputStream.open(Native Method)
at java.io.FileOutputStream.<init>(FileOutputStream.java:212)
at java.io.FileOutputStream.<init>(FileOutputStream.java:104)
at org.jacorb.naming.NameServer.main(NameServer.java:320)
java.lang.RuntimeException: c:/NS_Ref (No such file or directory)
at org.jacorb.naming.NameServer.main(NameServer.java:335)
Of course, if I explicitely pass the URI through console, everything goes fine
ns -Djacorb.naming.ior_filename=/tmp/CORBA/NS_Ref
The very strange thing is that, after the NameService is running, EVERY OTHER OBJECT can correctly and automatically resolve the initial reference of the NameService.
NamingContextExt nc = NamingContextExtHelper.narrow(orb.resolve_initial_references("NameService"));
The previous Java code returns a valid object. That does not make any sense for me.
And why does the NameService try to write its IOR inside a random file like C:\NS_Ref while I'm on Linux?
Any idea?
I thing you mixed up some different things in your question.
The location of the NS's IOR
The ability to read and use this IOR by other programs
First. Starting the NamingService is not affected by option ORBInitRef.NameService or any related commandline option. If you want the NamingService to drop it's IOR in a file, use
# The file where the name server drops its IOR
jacorb.naming.ior_filename=file:///tmp/CORBA/NS_Ref
as you already did. If this behaves different when using this as cmdline option, see 2.
Second. JacORB its config files are not OS specific - there is a mix of both Linux and Windows style. Don't rely on that.
Your call to ns will call the jaco script in JacORBs bin directory. Activate the verbosity stuff at the end of the file, then start ns again and see which jre and jacorb.home are really used. Look for configs. Remove ALL other configs you do not need.
Retry.
This
ns -Djacorb.naming.ior_filename=/tmp/CORBA/NS_Ref
looks fine, but shouldn't that
ORBInitRef.NameService=file:/tmp/CORBA/NS_Ref
read file:///tmp/CORBA/NS_Ref?
And this
c:/NS_Ref
is strange on Linux; that looks very windowzy to me; are you sure you've not mixed Win and Linux config files?
I'm developing this application to be used speceifically with Firefox (it's for internal use). Basically, we're using the sun.security stuff to read Firefox's KeyStore and sign data with the certs we get.
I've tested this on several machines and the results are varying, I can't seem to pinpoint the reason.
I've tested it on the latest ubuntu release, Firefox 3.6.13, using Java version 1.6.0_22, it works there. I also have a Windows XP laptop with the same Firefox version using Java version 1.6.0_17, where it works as well.
There are 2 other Windows XP laptops that it will not work on, giving the same error. They're running the same version of Firefox and using java version 1.6.0_17.
The error is:
java.security.ProviderException: Could not initialize NSS
at sun.security.pkcs11.SunPKCS11.<init>(SunPKCS11.java:183)
at sun.security.pkcs11.SunPKCS11.<init>(SunPKCS11.java:86)
at SignedMessage.SigningApplet.initializeCrypto(SigningApplet.java:327)
at SignedMessage.SigningApplet.init(SigningApplet.java:84)
at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.io.IOException: The specified procedure could not be found.
at sun.security.pkcs11.Secmod.nssLoadLibrary(Native Method)
at sun.security.pkcs11.Secmod.initialize(Secmod.java:186)
at sun.security.pkcs11.SunPKCS11.<init>(SunPKCS11.java:179)
... 5 more
Exception: java.security.ProviderException: Could not initialize NSS
From what I can tell it can't find the native nssLoadLibrary routine? The configuration file is pointing it to the Firefox install directory (where it can grab the nss3.dll or libnss3.so file). It does this across all pc's and all the paths in the configuration seem to be valid.
A sample config file, for what it's worth:
name=NSS
nssDbMode=readOnly
nssModule=keystore
nssSecmodDirectory="C:\\Documents and Settings\\user\\Application Data\\Mozilla\\firefox\\Profiles/8bzd2qqm.default"
nssLibraryDirectory=C:\Program Files\Mozilla Firefox
I was hoping someone would have a clue, or maybe some tips on getting further with debugging. I'm at a loss here.
I'm likely much too late for this to be of use to you, but I was having similar problems, and adding dist\WINXXX_DBG.OBJ\lib to my PATH resolved this issue.
Quick answer: Use the x86 jdk not the x64 jdk with NSS and JSS
Quick test against a NSS certificate database:
keytool -list -v -storetype pkcs11 -providerClass sun.security.pkcs11.SunPKCS11 -providerArg NSS_CONFIG_FIPS
where NSS_CONFIG_FIPS is the path to a config file pointing to an NSS database. This command will fail with a stack trace that matches the questioners error if it is a JDK issue and succeed if the JDK is configured properly (and if the config file is correct)
Note that my stack trace included the message:
Caused by: java.io.IOException: %1 is not a valid Win32 application.
I ran dumpbin /headers on the NSS dlls and found that the Mozilla built binaries are all 32 bit. I installed the x86 jdk and repointed JAVA_HOME. Everything began working.
To Vivek's point, NSS and the accompanying executables are very sensitive to the presence of the libraries. Be sure all of the .dll, .lib, and .chk files are present on the path. In particular, modutil.exe will fail certain commands without the chk files and the error messages are not helpful. Your NSS lib folder will need to include the NSS and NSPR lib folders, the jss4.dll and jss4.lib files, and the jss4.jar.
Also note that if you build NSS yourself, the libaries will not be signed with an approved code signing cert which will cause problems with JCA.
I have a problem when I try to instantiate Hibernate and connect with a MySQL database (see error message below).
Curiously enough the connection works fine using the exact same hibernate.cfg.xml file when running Junit tests but it refuses to work when run from Tomcat...
I am starting to run out of ideas.
Any clues or tip where to look?
Caused by: org.hibernate.HibernateException: Unable to instantiate default tuplizer [org.hibernate.tuple.entity.DynamicMapEntityTuplizer]
at org.hibernate.tuple.entity.EntityTuplizerFactory.constructTuplizer(EntityTuplizerFactory.java:110)
at org.hibernate.tuple.entity.EntityTuplizerFactory.constructDefaultTuplizer(EntityTuplizerFactory.java:135)
at org.hibernate.tuple.entity.EntityEntityModeToTuplizerMapping.(EntityEntityModeToTuplizerMapping.java:69)
at org.hibernate.tuple.entity.EntityMetamodel.(EntityMetamodel.java:323)
at org.hibernate.persister.entity.AbstractEntityPersister.(AbstractEntityPersister.java:456)
at org.hibernate.persister.entity.SingleTableEntityPersister.(SingleTableEntityPersister.java:131)
at org.hibernate.persister.PersisterFactory.createClassPersister(PersisterFactory.java:84)
at org.hibernate.impl.SessionFactoryImpl.(SessionFactoryImpl.java:267)
at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1341)
at se.fmt.atlantism.util.HibernateUtil.buildSessionFactory(HibernateUtil.java:16)
... 38 more
Caused by: java.lang.NullPointerException
at org.hibernate.tuple.entity.EntityTuplizerFactory.constructTuplizer(EntityTuplizerFactory.java:107)
... 47 more
I'm writing this for future Googlers and reference.
I've done some more research and the root source of the problem is still not known. However the following article throw me on the right track.
http://www.howtogeek.com/howto/linux/installing-tomcat-6-on-ubuntu/
It seems like the Tomcat (version 6 at least) packages available in Ubuntu (and Debian) are not working correctly. Instead I installed Tomcat using the following guide:
http://www.ctrip.ufl.edu/tomcat6-debian-lenny-howto
While this might not be the premium choice of installation it seems necessary to get Tomcat version 6 running without problems on Ubuntu and/or Debian Lenny.
In my case, this error was resolved by switching the <dependency/> order in my pom.xml. When hibernate (3.2.7.ga) comes before hibernate-annotations (3.4.0.GA) this error occurs. The other way around, it works fine. This is the case even with scope=compile.
I would guess that you need to tweak your classpath, except that (assuming you've dropped both jars in WEB-INF/lib) it should alpha-sort in the correct order. But maybe this will give someone a hint on how to move forward.
In my case it was a simple mistake - the config file *.hbm.xml had a property that the mapped object didnt have! I also heard of cases of that error apearing when you misspell a get/set function - very similar to my case.
I was facing the same problem. It went away after I downloaded "javassist.jar" and put it in the classpath: http://www.java2s.com/Code/Jar/JKL/Downloadjavassistjar.htm
This is how the Tomcat daemon process looks:
root 2605 0.0 0.0 16584 376 ? Ss 15:39 0:00
/usr/bin/jsvc -user tomcat6
-cp /usr/share/java/commons-daemon.jar:/usr/share/tomcat6/bin/bootstrap.jar
-outfile SYSLOG -errfile SYSLOG -pidfile /var/run/tomcat6.pid
-Djava.awt.headless=true -Xmx128M
-Djava.endorsed.dirs=/usr/share/tomcat6/endorsed
-Dcatalina.base=/var/lib/tomcat6 -Dcatalina.home=/usr/share/tomcat6
-Djava.io.tmpdir=/tmp/tomcat6-temp -Djava.security.manager
-Djava.security.policy=/var/lib/tomcat6/work/catalina.policy
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
-Djava.util.logging.config.file=/var/lib/tomcat6/conf/logging.properties
org.apache.catalina.startup.Bootstrap
This is how the Tomcat process looks when run from within Eclipse using the Sysdeo Tomcat launcher plugin:
(this one actually works)
jzaruba 2655 19.7 4.5 358304 46152 ? Sl 15:43 0:01
/usr/lib/jvm/java-6-sun-1.6.0.15/bin/java
-agentlib:jdwp=transport=dt_socket,suspend=y,address=localhost:37377
-Dcatalina.home=/usr/share/tomcat6
-Djava.endorsed.dirs=/usr/share/tomcat6/endorsed
-Dcatalina.base=/var/lib/tomcat6 -Djava.io.tmpdir=/var/lib/tomcat6/temp
-Dfile.encoding=UTF-8 -classpath
/usr/share/tomcat6/bin/bootstrap.jar:/usr/lib/jvm/java-6-sun-1.6.0.15/lib/tools.jar
org.apache.catalina.startup.Bootstrap start
The working one (Eclipse launched) is run using java-6-sun-1.6.0.15, I'm Windows user so I don't know how to tell which JRE is used for /usr/lib/jsvc (looking at it though), but my guess would be it is some OpenJDK... Could this be the difference?
update: jsvc probably uses the same JRE Sysdeo Tomcat launcher does