now i'm desparate. I feel like i'm turning round. when i believe solve something then i break something else.
started using this mac this week.In the process of setting up my environment i face some challenge.I got a maven project which uses cargo plugin to publish to tomcat working fine.for that i had to google to create the /etc/launchd.conf file.For some reasons web applications created in netbeans cannot publish to tomcat server i thought it was due to tomcat permission but when i set chmod 777 /Library/tomcat020
sh-3.2# ls -l /Library/tomcat6020
total 136
-rw-r--r--# 1 highjo admin 6148 Nov 4 16:03 .DS_Store i have this for file
drwxr-xr-x# 26 highjo admin 884 Nov 4 16:03 bin and this for folder
i was expecting to be rwxrwxrwx.that's the first problem.
second the first project in maven that was working is not any more.
showing
org.apache.maven.surefire.booter.SurefireExecutionException: Unable to create file for report: /myproject/target/surefire-reports/com.myproject.dao.hibernate.someDAOImplTest.txt (Permission denied); nested exception is java.io.FileNotFoundException: /myproject/target/surefire-reports/com.myproject.dao.hibernate.someDAOImplTest.txt (Permission denied); nested exception is org.apache.maven.surefire.report.ReporterException: Unable to create file for report: /myproject/target/surefire-reports/com.myproject.dao.hibernate.someDAOImplTest.txt (Permission denied); nested exception is java.io.FileNotFoundException: /myproject/target/surefire-reports/com.myproject.dao.hibernate.someDAOImplTest.txt (Permission denied)
same Exception and permission denied anytime i need to run a web app which is supposed to be published on tomcat.
Is Netbeans lacking privileges to access those files?I 'm running late to set up the developement environment.I need help! thanks for reading this
As for the chmod, you seem to be expecting recursive behavior (since you're looking at the permissions what's IN the directory that you chmod, rather than the directory itself). In that case, you should be using chmod -R.
You say chmod 777 /Library/tomcat020, but then ls /Library/tomcat6020 ( note extra 6 )
Related
I am trying to use a tool that, in two steps, analyzes code smells for android.
In the first step, the tool parses an apk and generates within a directory .db files that should then be converted to CSV files in the next step; however, whenever I try to run the second step, the console returns the following error:
java.io.IOException: Unable to create directory path [/User/Desktop/db2/logs] for Neo4j store.
I think it is a Neo4J configuration problem.
I am currently running the tool with the following Java configuration:
echo $JAVA_HOME
/home/User/openlogic-openjdk-11.0.15
update-alternatives --config java
* 0 /usr/lib/jvm/java-11-openjdk-amd64/bin/java 1111 auto mode
To be safe, I also started Neo4J, which returned the following output
sudo systemctl status neo4j.service
neo4j.service - Neo4j Graph Database
Loaded: loaded (/lib/systemd/system/neo4j.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2022-07-06 20:11:04 CEST; 16min ago
Main PID: 1040 (java)
Tasks: 57 (limit: 18901)
Memory: 705.4M
CPU: 16.639s
CGroup: /system.slice/neo4j.service
└─1040 /usr/bin/java -cp "/var/lib/neo4j/plugins:/etc/neo4j:/usr/share/neo4j/lib/*:/var/lib/neo4j/plugins/*" -XX:+UseG1GC -XX:-OmitStackTraceInFastThrow -XX:+AlwaysPreTouch -XX:+UnlockExper>.
How can I solve this?
You posted this error:
java.io.IOException: Unable to create directory path [/User/Desktop/db2/logs] for Neo4j store.
From that error, it looks like:
Neo4j was installed at "/User/Desktop/db2"
The permissions for that directory do not have "write" permission
I tried to reproduce this locally using Neo4j Community 4.4.5, following the steps below.
I do see an IOException related to "logs", but it's slightly different from what you posted. Perhaps we're on different versions of Neo4j.
Open terminal into install directory: cd neo4j
Verify "neo4j" is stopped: ./bin/neo4j stop
Rename existing "logs" directory: mv logs logs.save
Remove write permission for the Neo4j install: chmod u-w .
Start neo4j in console mode: ./bin/neo4j console
Observe errors in console output
2022-07-08 03:28:38.081+0000 INFO Starting...
ERROR StatusLogger Unable to create file [****************************]/neo4j/logs/debug.log
java.io.IOException: Could not create directory [****************************]/neo4j/logs
...
To fix things, try:
Get a terminal into your Neo4j directory:
cd /User/Desktop/db2
Set write permissions for the entire directory tree:
chmod u+w -R .
Start neo4j in console mode:
./bin/neo4j console
If this works and you're able to run neo4j fine, it points to an issue with user permissions when running neo4j as a system service.
The best steps from there depend on the system, your access, how comfortable you are making changes, probably other things. An easy, brute-force hammer would be to manually create each directory you discover (such as "/User/Desktop/db2/logs") and grant premissions to all users (chmod ugo+w .), then try re-running the service, see what errors pop up. Repeat that until you're able to run the service without errors.
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 am new to Apache Derby database,
When i am trying to crate new database using the following command i am getting the below problem
C:\>java org.apache.derby.tools.ij
ij version 10.10
ij> connect 'jdbc:derby:Mynewdb;create=true';
Mon Mar 03 20:17:32 IST 2014 Thread[main,5,main] java.io.FileNotFoundException: derby.log
(Access is denied)
----------------------------------------------------------------
Mon Mar 03 20:17:33 IST 2014:
Booting Derby version The Apache Software Foundation - Apache Derby - 10.10.1.1 - (1458268): instance a816c00e-0144-886a-02f2-000000b8d0b0
on database directory C:\Mynewdb with class loader sun.misc.Launcher$AppClassLoader#11b86e7
Loaded from file:/C:/db-derby-10.10.1.1-bin/db-derby-10.10.1.1-bin/lib/derby.jar
java.vendor=Sun Microsystems Inc.
java.runtime.version=1.6.0_23-b05
user.dir=C:\
os.name=Windows 7
os.arch=x86
os.version=6.1
derby.system.home=null
Database Class Loader started - derby.database.classpath=''
A file named derby.log will be created in the current working directory when you run ij (or attempt to use embedded Apache Derby in some other application). From the post, it appears you are executing this from C:\ and the user you are logged on as does not have write access to that directory: change to a directory where the user has permission to create a file and retry.
Note it is possible to suppress this log file (though I have not yet done this myself). See Getting rid of derby.log. However, suppressing the log file would just result in another failure in your case because the database will be created on the file system relative to the current directory. That is, an attempt to create the directory named Mynewdb in the current directory, C:\, would also fail for the same reason. It is possible to specify a path for the database to avoid creating in the current working directory:
ij> connect 'jdbc:derby:/tmp/test_db;create=true';
user.dir=C:\
os.name=Windows 7
Windows 7 (and up?) doesn't let you write files to the root directory in most cases. You should cd to another directory before starting ij. e.g. cd \Users\YOUR_USER_NAME and you should be good to go.
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?
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.