We have done a clean install of Servoy 5: all database (including repository) deleted and recreated, Servoy 4 uninstalled (temp/working folders deleted).
After the installation we have used Developer to create the connections. We have built the repository using Developer. No extra or old file has been added/replaced.
Then we have started successfully the service. But when we try to import our solution (.servoy file made using Servoy 5 Developer), nothing happens and we get the following error in the server logs:
org.apache.commons.fileupload.FileUploadBase$IOFileUploadException: Processing of multipart/form-data request failed. C:\Windows\system32\config\systemprofile\AppData\Local\Temp\upload_5417799d_125499c007e__7ff7_00000000.tmp (The system cannot find the path specified)
at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:367)
at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:310)
at com.servoy.j2db.server.servlets.ConfigServlet.Zi(ConfigServlet.java:2213)
at com.servoy.j2db.server.servlets.ConfigServlet.service(ConfigServlet.java:839)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:567)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454)
at java.lang.Thread.run(Unknown Source)
Caused by: java.io.FileNotFoundException: C:\Windows\system32\config\systemprofile\AppData\Local\Temp\upload_5417799d_125499c007e__7ff7_00000000.tmp (The system cannot find the path specified)
at java.io.FileOutputStream.open(Native Method)
at java.io.FileOutputStream.(Unknown Source)
at java.io.FileOutputStream.(Unknown Source)
at org.apache.commons.io.output.DeferredFileOutputStream.thresholdReached(DeferredFileOutputStream.java:165)
at org.apache.commons.io.output.ThresholdingOutputStream.checkThreshold(ThresholdingOutputStream.java:221)
at org.apache.commons.io.output.ThresholdingOutputStream.write(ThresholdingOutputStream.java:127)
at org.apache.commons.fileupload.util.Streams.copy(Streams.java:101)
at org.apache.commons.fileupload.util.Streams.copy(Streams.java:64)
at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:362)
… 17 more
The folder Temp of the path didn’t exist so we have created it to see it will fix it but nothing changed.
As Servoy 5 allows to import solutions through Developer we have tried it as well. But this time we got this error during the import:
org.hibernate.MappingException: No Dialect mapping for JDBC type: -9
We use PostgreSQL 8.4 and the database connections look fine.
We solved the problem of import through the admin page.
In fact it was just because after the install the Service was run on Local System Account which doesn’t have enough rights to write into C:\Windows\system32\config\systemprofile\AppData\Local\Temp\ directory on Windows Server 2008
However now during the import we have the same error as the one we get when we import through Developer:
org.hibernate.MappingException: No Dialect mapping for JDBC type: -9
We think it’s an issue with datatypes compatibility between PostgreSQL 8.4(used on the server) and MS SQL Server 2008 Express (used on development PC). But we have not found the source of the problem yet.
Are you using some non-standard datatypes like ‘Money’ in MSSQL ?
Hi,
I think we found what was the problem! It was the type “nvarchar” from MS SQL which is not supported by PostgreSQL.
The thing is that we had the type varchar in the past and never changed it to nvarchar.
However the person who made the .servoy file for the import, changed his PC and moved from MS SQL 2000 to MS SQL 2008. It’s the only thing which changed.
2010-03-25 15:27:02,125 ERROR [http-8080-6] com.servoy.j2db.util.Debug - Throwable
org.apache.commons.fileupload.FileUploadBase$IOFileUploadException: Processing of multipart/form-data request failed. C:\Windows\system32\config\systemprofile\AppData\Local\Temp\upload_662e8664_127976d498c__7fef_00000000.tmp (The system cannot find the path specified)
Did you change something on the Servoy Server admin page (from you comments below)? We cannot find it.
We solved the problem of import through the admin page.
In fact it was just because after the install the Service was run on Local System Account which doesn’t have enough rights to write into C:\Windows\system32\config\systemprofile\AppData\Local\Temp\ directory on Windows Server 2008
We tried changing the Windows service account login for Servoy Server from the Local System Account to the administrator account (with full rights), but the Servoy Service will not start.
Would you mind sharing more details on how you got yours to work?
I’m a bit confused: you’ve been talking about not being able to import, but from the quote above I find you can not start the Service at all?
Can you clarify more on this and maybe post the servoy_log or other error message?
From my experience I can only say that the import issue is just a matter of ‘rights’. I’ve been struggling with it last week and finally got it to work when running the servoy service with full admin rights…
I have a solution that was developed on a workstation computer. I exported the solution to a .servoy file and now want to install it on our server. On the server, I launch Servoy Server and click on the Solutions link where I select the .servoy file, and click on the import button. The screen immediately changes to an empty window about 1 inch high within the bounds of the Servoy Server screen at the top. I again click on the Solutions link, and observed that the .servoy solution I selected did not import. Checking the Servoy Server log file, I found the throwable error that I posted earlier.
Searching the forum for help, I came across this post and changed the Servoy Sever service credentials as Foobrother said he did. I changed the Local System Account to my login account (with administrator rights) and later to the Administrator account. After each change, I attempted to start the Servoy Server service, and got an error message stating that neither of these two accounts had the proper rights, and the Servoy Server service would not start. When I changed back to the Local System Account, the Servoy Server service would start, but I was back to not being able to import the .servoy solution. Ugh!
What did you do to give the Servoy Server service full rights? I would have thought that letting the Servoy Server service run under the Administrator account would have worked. I even disabled the UAC thinking that would help, but it didn’t.
The odd thing is that earlier this month after installing Servoy 5.1 on our server, I was able to install a different .servoy solution with no problem. I haven’t touched the server since then and don’t know what changed. So, you are not the only one confused!
kwpsd:
What did you do to give the Servoy Server service full rights? I would have thought that letting the Servoy Server service run under the Administrator account would have worked. I even disabled the UAC thinking that would help, but it didn’t.
Basically I did just 1 thing, modify the properties of the server and let this run as admin. (I also did this for my SQL service, but wasn’t really needed if I’m not mistaken)
A 2nd thing which might bug you: do you use a local admin account or is this your domain admin account?
What I’ve seen before (but this is more system admin stuff, which I’m really not): when you use a domain admin account, you have to create the domain admin as a user on this specific machine as well.
If you don’t do this, you might be perfectly able to work with the machine, but as soon as you try to copy a file (can be a simple text file copied to the desktop), the machine comes back with an error saying that you don’t have sufficient rights…
The above makes perfect sense when the machine uses separate, private profiles. When a domain user (even admin I guess…) is trying to write files to a location, it just can’t find this location.
kwpsd:
After each change, I attempted to start the Servoy Server service, and got an error message stating that neither of these two accounts had the proper rights, and the Servoy Server service would not start.
Doesn’t ring a bell and I didn’t see this behaviour. It looks like the machine can’t verify the credentials (I assume you know how to type ‘Administrator’ and know the correct password… )
I’d say have a close look at which account (local/domain) your machine is really using.
What mboegem said is right.
But are you sure your Admin accounts are well setup to run this service? Because normally an Admin account should definitely be able to do it, as a simple local account can
Personnally I used a local administrator account as everything is hosted on the same server. But, like mboegem said, If your solution is working with files hosted on another server on the domain, the account running the service has to have access rights to this server.
As mboegem said, please provide us the logs of Servoy after you tried to start the service with the admin account to get more information.
kwpsd:
The odd thing is that earlier this month after installing Servoy 5.1 on our server, I was able to install a different .servoy solution with no problem. I haven’t touched the server since then and don’t know what changed. So, you are not the only one confused!
the thing is i think that the solution that failed was way bigger then the solution that did import?
We use commons upload that will use disk if the upload is big so that it doenst have to keep it in memory.
So small uploads are handled in memory and dont give a problem
But for big uploads a temp dir will be used. And if the temp dir that is configured for java isnt writeable… yes you have a problem…
Here is the error message from the Servoy Application Server:
2010-03-30 10:43:40,848 ERROR [http-8080-5] com.servoy.j2db.util.Debug - Throwable
org.apache.commons.fileupload.FileUploadBase$IOFileUploadException: Processing of multipart/form-data request failed. C:\Windows\system32\config\systemprofile\AppData\Local\Temp\upload__5269ac97_1279d0b5b14__7fef_00000001.tmp (The system cannot find the path specified)
at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:367)
at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:310)
at com.servoy.j2db.server.servlets.ConfigServlet.Zj(ConfigServlet.java:1457)
at com.servoy.j2db.server.servlets.ConfigServlet.service(ConfigServlet.java:2465)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:567)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454)
at java.lang.Thread.run(Unknown Source)
Caused by: java.io.FileNotFoundException: C:\Windows\system32\config\systemprofile\AppData\Local\Temp\upload__5269ac97_1279d0b5b14__7fef_00000001.tmp (The system cannot find the path specified)
at java.io.FileOutputStream.open(Native Method)
at java.io.FileOutputStream.(Unknown Source)
at java.io.FileOutputStream.(Unknown Source)
at org.apache.commons.io.output.DeferredFileOutputStream.thresholdReached(DeferredFileOutputStream.java:165)
at org.apache.commons.io.output.ThresholdingOutputStream.checkThreshold(ThresholdingOutputStream.java:221)
at org.apache.commons.io.output.ThresholdingOutputStream.write(ThresholdingOutputStream.java:127)
at org.apache.commons.fileupload.util.Streams.copy(Streams.java:101)
at org.apache.commons.fileupload.util.Streams.copy(Streams.java:64)
at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:362)
… 17 more
the ‘Temp’ folder does not exist which explains the error message. I guess the bigger question is why is Servoy Application Server trying to read from a folder that doesn’t exist?
the thing is i think that the solution that failed was way bigger then the solution that did import?
The solution that I am trying to load is 2.4 MB whereas the older solution was 13 MB. However, I did upgrade the Servoy Application Server from 5.x (sorry, I cannot remember if it was 5.0 or 5.1) to 5.1.1 before this all happened.
Our server is a Windows Vista-based computer running Servoy Server service under the local System account…there is no domain and there is no password for this account.
We changed the password on the Windows Vista Administrator’s account. Once we changed the password, Servoy Application Server service would run using this account, and we were able to import the solution. We never got Servoy Application Server service to run under the SYSTEM account (the default for services).
We did notice that below the Windows folder was another folder titled Windows.old with a recent date. We speculate that a Windows update modified our Windows settings which is why the service would no longer run under the SYSTEM account.
I’ve just had the same problem.
Ran command line with administrative rights, started database and application services from there and this fixed the problem.
Thanks guys.