[
https://issues.apache.org/jira/browse/HTTPCLIENT-876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761571#action_12761571
]
Ortwin Glück commented on HTTPCLIENT-876:
-----------------------------------------
The interesting bit is "Configuring a Context workDir will override use of the
Host workDir configuration".
And from http://tomcat.apache.org/tomcat-5.5-doc/config/context.html
"Only if a context file does not exist for the application in the
$CATALINA_HOME/conf/[enginename]/[hostname]/; in an individual file at
/META-INF/context.xml inside the application files. If the web application is
packaged as a WAR then /META-INF/context.xml will be copied to
$CATALINA_HOME/conf/[enginename]/[hostname]/ and renamed to match the
application's context path. Once this file exists, it will not be replaced if a
new WAR with a newer /META-INF/context.xml is placed in the host's appBase."
Maybe you don't need GoDaddy's support :-)
> Calling httpClient.execute(post) on a shared server causes security error
> (WRITE not allowed to protected area on disk)
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: HTTPCLIENT-876
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-876
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient
> Affects Versions: 4.0 Final
> Environment: Java 5.0, Tomcat
> Reporter: Clifford
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> I run my JSP modules on a shared server at GoDaddy.com, one of the largest
> hosting companies in the USA. They have strict security on the servers which
> disallows writing to any disk files unless they are in the /temp directory.
>
> When I first tried to execute a module I wrote using HttpClient, I got a
> security write-not-allowed error. I looked at the stack trace and found out
> that org.apache.http.impl.client.DefaultHttpClient.java (at source line 197)
> calls org.apache.http.util.VersionInfo method loadVersionInfo, and that class
> (at source line 248) tries to do a FILE WRITE after not finding a property
> file containing the version#. That WRITE is disallowed by my hosting, thus
> causing my HttpClient call to fail. I can provide more details if you like.
>
> I worked around the problem by commenting out the call to loadVersionInfo and
> recompiling DefaultHttpClient, but MANY MANY programmers will run into this
> issue, so I would label it an urgent bug that needs to be fixed. Suggestions
> for the fix could be 1) hard-code the version in a new final static variable
> of DefaultHttpClient, or 2) Write the Properties file containing the
> HttpClient version# to a directory within /temp.
> The stack trace (transcribed from a printout) is:
> java.security.AccessControlException: access denied (java.io.FilePermission
> /web/tomcat/work/hosting/dir.dotgreen.org/.../loader/META-INF write) at ... 5
> levels of java.security.* then
> java.io.File.mkdir
> WebappClassLoader.findResourceInternal
> WebappClassLoader.findResource
> WebappClassLoader.getResourceAsStream
> VersionInfo.loadVersionInfo (line 244)
> DefaultHttpClient.createHttpParams (line 197)
> AbstractHttpClient.getParams (line 293)
> DefaultHttpClient.createClient (line 2)
> AbstractHttpClient.getConnectionManager (line 312)
> DefaultHttpClient.createHttpContext (line 254)
> AbstractHttpClient.execute (line 618)
> AbstractHttpClient.execute (line 576)
> AbstractHttpClient.execute (line 554)
> then a dozen JSP/catalina locations that are irrelevant
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
