steve1376656734:
It may also be worth mentioning the SERVOY_USER_HOME property in the wiki and stating that it should be set in the java options as being a Unix bod an environment variable is set at the shell level not the Java level!
https://wiki.servoy.com/display/DOCS/WAR+Deployment
there the SERVOY_USER_HOME is quite explained. (that it is a java system property)
Hi
I am having the same issues as Steve describes here trying to install Servoy 7 on a Tomcat instance within a Docker Container.
I have added the SERVOY_USER_HOME variable and used both /home and /usr/local/tomcat both of which have had 777 permissions set with chmod. ( I hasten to add this is all running locally at the moment)
I have re deployed the war which has created the solution folder however it has not apparently created the .servoy folder or a log file ??
Can you clarify where the SERVOY_USER_HOME directly should be located, how this is set ? I am guessing its in the Tomcat defaults along with CATALINA_HOME etc
I suspect the issues here are permissions related and the fact I can not find a .servoy file is the problem but without a log of any sort I am a bit stuck. The console is reporting the following none of which appears to be pointing at an inability to write .servoy
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
java.lang.Thread.run(Thread.java:745)
09-Aug-2016 10:15:29.253 SEVERE [ContainerBackgroundProcessor[StandardEngine[Catalina]]] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesRmiTargets Found RMI Target with stub class class [sun.rmi.registry.RegistryImpl_Stub] and value [RegistryImpl_Stub[UnicastRef2 [liveRef: [endpoint:127.0.0.1:1099,com.servoy.j2db.server.rmi.tunnel.WrappingCompressingRMIServerSocketFactory@6f48db18,com.servoy.j2db.server.rmi.tunnel.WrappingCompressingRMIClientSocketFactory@268427,objID:[0:0:0, 0]]]]]. This RMI Target has been forcibly removed to prevent a memory leak.
09-Aug-2016 10:16:19.304 INFO [localhost-startStop-3] org.apache.catalina.startup.HostConfig.deployWAR Deploying web application archive /usr/local/tomcat/webapps/clipper.war
09-Aug-2016 10:16:30.462 INFO [localhost-startStop-3] org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug logging for this logger for a complete list of JARs that were scanned but no TLDs were found in them. Skipping unneeded JARs during scanning can improve startup time and JSP compilation time.
09-Aug-2016 10:16:30.904 INFO [localhost-startStop-3] org.apache.catalina.startup.HostConfig.deployWAR Deployment of web application archive /usr/local/tomcat/webapps/clipper.war has finished in 11,600 ms
Hi Gordon,
After a lot of experimenting with WAR deployments the best advice I can give you is to make sure that the user that is running the Tomcat process has write access to their own home directory. This sounds a little obvious but when I followed some internet tutorials to install the Tomcat server you end up creating the directory as the root user but then add a new user to the system to run the Tomcat process and set the directory you created as root to be the home directory. The Tomcat user then does not have write access to their own home directory but the Tomcat server will run without problems - until you try to deploy a Servoy WAR!
The SERVOY_USER_HOME variable can be used to override the default home directory and can be set in one of two ways. The first is by adding it as a parameter to the JVM directly or by adding it to the JAVA_OPTS string in the Tomcat startup script. The format is -DSERVOY_USER_HOME=yourdir.
Since setting the permissions correctly on the all the directories I have not had to use the SERVOY_USER_HOME variable at all.
Hope this helps
Steve
Hi Steve, I am certain your dead right about the permissions and the tomcat user. The problem is I am using a docker container which is a bit peculiar in that it appear to be a super cut down version of linux with one process Tomcat and only a root user. Its apparently working i.e. you can see the default home page. I will go and investigate how Tomcat gets to be a user and where its home is located as currently its suggesting CATALINA_HOME is /usr/local/tomcat which I have already given max permissions
thanks again for your input I will post my findings if any
Gordon
Steve
Can I just be really clear about the user here. Are you talking about the TOMCAT user as set in /usr/local/tomcat/conf/ which is by default blank and affect the Tomcat management page OR the linux user that Tomcat is logged in as which as far as I can see is ROOT so should have permissions ??
Cheers
Gordon
The linux Tomcat user. It is not best practice to run the Tomcat process as root so I always have a specific user for it (called tomcat and in the group tomcat). If your process is genuinely running as root then you shouldn’t have any permission issues but I would also check the Tomcat startup script as this often sets the user that Tomcat will run as.
Steve
Steve, thanks for your help much appreciated
Interesting developments on this which Servoy may want to consider:
I have installed two war deployments one in Servoy 8 and the other Servoy 7. The Servoy 8 version correctly adds .servoy folder to the /root directory where this version of Tomcat is running, this however does not happen with Servoy 7.
Accepting this should not be running as root, I have however experimented with the /root folder and version setting 777 privileges to /root so there is no way that Tomcat has a permissions issue as a) its root and b) the target home is 777 enabled
What is really hard to understand is why the Servoy war deployment would differ from one version to the other and why both fail to function with the ‘official’ version of Tomcat in a container ? this would appear to be the benchmark version with no tweaks. The fact the container runs as root may well be bad idea for Tomcat, however it does mean there is less likelihood of a permissions issue preventing this from running
so all in all no progress made yet
Cheers
Gordon
The other worry development on this is this terminal message
10-Aug-2016 08:51:45.599 WARNING [localhost-startStop-1] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [funky] appears to have started a thread named [acceptor-0.0.0.0/0.0.0.0:1099] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread:
java.net.PlainSocketImpl.socketAccept(Native Method)
java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:398)
java.net.ServerSocket.implAccept(ServerSocket.java:530)
java.net.ServerSocket.accept(ServerSocket.java:498)
com.sebster.tunnel.socket.ServerSocketSocketAcceptor.accept(ServerSocketSocketAcceptor.java:8)
com.sebster.tunnel.impl.c.run(c.java:5)
java.lang.Thread.run(Thread.java:745)
10-Aug-2016 08:51:45.601 SEVERE [localhost-startStop-1] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesRmiTargets Found RMI Target with stub class class [sun.rmi.registry.RegistryImpl_Stub] and value [RegistryImpl_Stub[UnicastRef2 [liveRef: [endpoint:127.0.0.1:1099,com.servoy.j2db.server.rmi.tunnel.WrappingCompressingRMIServerSocketFactory@22d859fe,com.servoy.j2db.server.rmi.tunnel.WrappingCompressingRMIClientSocketFactory@268427,objID:[0:0:0, 0]]]]]. This RMI Target has been forcibly removed to prevent a memory leak.
These two being the key issues:
The web application [funky] appears to have started a thread named [acceptor-0.0.0.0/0.0.0.0:1099] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread:
This RMI Target has been forcibly removed to prevent a memory leak.
I have opened the port 1099 to the host and it should be accepting traffic so I am not seeing why this should be a problem bit I guess shutting it down altogether would be a probably cause of issues
Not sure in what version you get that leak stuff (that tomcat checks) but in the latest releases of servoy we tried to clean up as much as possible when the WAR is undeployed (so when you redeploy the war on a running tomcat)
If you use smart clients then you have to start the rmi port (that will leak no matter what some stuff as far as i know that can’t be fixed by servoy)
if you don’t use smart clients then do turn of the rmi port when exporting the WAR
I don’t know what the difference could be between servoy 7 or 8, i think both should just make that dir at the moment it needs it. But running it at root is not the best thing.
I guess in this situation the best thing to do is define the -DSERVOY_USER_HOME= to point to a /xxx/yyy writable dir for tomcat
Firstly thanks to both of you @johan and @steve for your help, I have now at least got to a point where I can see the admin even if the solutions won’t at this stage run.
@johan
As you suggest I have turned off the RMI port but will review this now the solution is running as it would appear to be a warning and not a show stopper
The difference between 7 and 8 is 7 will not make the .servoy directory or appears unable, whereas 8 will and if you install 8 first then 7 will install using .servoy folder created by 8. Interestingly it creates the servoy_log.txt and servoy_server.properties files but does not write anything to them nor does Servoy when running. Servoy 8 creates import.ser, servoy_log.txt, servoy_server.properties and solution.servoy all of which have the same permissions as 7 and are written to.
As you both mentioned not running Tomcat as root I looked into why the Docker Containers would do this. it appears that the way the docker containers work is encapsulated in their own space. As a consequence they are effectively running chroot’d in their own space hence only have access within the container that has no other features. I will however try to get this to run as tomcat as @steve suggested.
This whole exercise was started to get Docker to run Servoy which is partially has. The reason for this is I like the idea of having a local Tomcat server running in a contained space that can be used for development and once working pushed live onto Amazon Elastic Cloud without alteration. It also makes working with other developers significantly easier as each of us have effectively the same matched solution.
Thanks again for your help, I hope to soon have a working containerised version of servoy on the cloud serving customers
Best
Gordon
maybe have a look at this:
https://docs.docker.com/engine/tutorials/dockervolumes/
then mounting a piece of the host as a dir that is then used inside the docket as the “home” dir
the log file should be filled when there is really some logging…
the servoy properties file is i think only really filled when you press “save settings” on the admin page. Then the current settings are stored.
If you don’t do that, you really use the shipped servoy settings as is, then that is even better for a docker (then the settings are fixed when deployed)
for servoy 8 we stored a bit more and that is related to the active solution that you export. That file is a test for us if you just redeploy or restart tomcat that we don’t do the ‘import’ (nothing is changed)
We just start right away and read in the serialized solution
Only when you drop a new war with a new serialized soluiton, we see that the timestamps are newer inside the war and we will do a real import (of database metadata ,i18n data and so on) and overwrite the files in the home dir.
Thanks Johan I will study this further …
Cheers
Gordon
For the benefit of others and me when I forget:
Servoy 8:
Copy the war file you have created to the tomcat server. IF your using docker as I am you use:
docker cp ~/Desktop/test.war tomcat:/usr/local/tomcat/webapps/test.war
This copies the war from my desktop to the locally installed docker container.
Once copied tomcat will install the Servoy solution and you can access i.e. with a URL such as
http://localhost:32777/test/servoy-webclient/
Docker:
For those wishing to try this it is a great way to install tomcat on your local machine and deploy completed tested solutions to the cloud. The quick instructions are
Install docker by following the instructions on docker.com. This provides you with virtual light weight host machine (linux) and a gui (kitematic). Open Kinematic, select new and search for Tomcat. I used the official version first option which was quick to install, up to date and consistent.
Once installed you can access the container via Kitematic using the Exec button. This takes you direct to Tomcat home in the container so to get to webapps where wars are installed type ‘cd webapps’ followed by ‘ls’ you will recognise the folder structure from the Servoy Server folder in developer.
Tomcat within the container is installed in /usr/local/tomcat
Tomcat home in the default install is /root/.servoy/server/[yoursolution]
To copy your war from your desktop:
to get the servoy log file back from docker to your desktop
docker cp tomcat:/root/.servoy/server/[yoursolution]/servoy_log.txt ~/Desktop/
other files in the same directory include
import.ser
servoy_log.txt
servoy_server.properties
solution.servoy
uploads
IF you want to try again/reset your container you can either delete it:
Hit X next to container in Kitematic
type 'docker rmi tomcat [or your container ID both of which are got from ‘docker images’]
The other option is to retain the container and remove the servoy files using the DOCKER terminal window (Exec in Kitematic)
cd /usr/local/tomcat/webapps/
rm [yoursolution].war
rm -R [yoursolution]
cd /root/.servoy/server/
rm [yoursolution]
I cd into the folder to make sure I know where I am you can do this direct with rm -R /root/.servoy/server/[yoursolution] if your brave
The crucial thing about docker as opposed to using a service OR installing Tomcat on your local machine is if you mess up you can start again with no impact on your local machine and no security risk its all local. The second key thing is if you get this working and your happy with it you can deploy to Amazon AWS, Google etc all of whom offer container services many of which are free at the lower use tiers.
I hope this helps someone and more than likely I will need to notes again at some point soon
best
Gordon
…thanks again to Steve and Johan for this input it was a great help. Do bear in mind two things that the guys suggested all of the above works in root it is better if you can get tomcat to work in its own user space. Secondly install a storage volume in docker which I am working at understanding. I will write up a detailed how to if anyone is interested contact me direct