[
https://issues.apache.org/jira/browse/HADOOP-5023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12676383#action_12676383
]
Chris Douglas commented on HADOOP-5023:
---------------------------------------
bq. Did you run "ant tar" first in the $HADOOP_ROOT dir. hadoop-core-*.jar is
needed for the war file. We could have used a static lib dir to hold a
pre-compiled hadoop jar, but that would bring some redundancy as a whole. I am
not sure in this case which way should we go. Either have a static hadoop jar
to make the proxy code more independent but add some redundancy or have some
dependency on the hadoop build but have a cleaner structure. I follow the
latter in the patch. I can change if necessary.
I didn't, but that's only half of the objection (even after running {{ant
all-jars}}, even {{ant tar}} the test still fails). The other half is that,
running with {{-Dtestcase=FOO}}, the only tests that run should be those named
FOO. The error I'm seeing:
{noformat}
test:
[echo] Please take a deep breath while Cargo gets the Tomcat for running
the servlet tests...
[cactus] -----------------------------------------------------------------
[cactus] Running tests against Tomcat 5.x @ http://localhost:8087
[cactus] -----------------------------------------------------------------
[cactus] Deploying [/snip/hadoop/build/contrib/hdfsproxy/target/test.war] to
\
[/snip/hadoop/build/contrib/hdfsproxy/target/tomcat-config/webapps]...
[cactus] Tomcat 5.x starting...
[cactus] Tomcat 5.x started on port [8087]
BUILD FAILED
/snip/hadoop/build.xml:772: The following error occurred while executing this
line:
/snip/hadoop/src/contrib/build.xml:48: The following error occurred while
executing this line:
/snip/hadoop/src/contrib/hdfsproxy/build.xml:155: Failed to start the container
after more than [180000] ms. \
Trying to connect to the
[http://localhost:8087/test/ServletRedirector?Cactus_Service=RUN_TEST] \
test URL yielded a [-1] error code. Please run in debug mode for more details
about the error.
{noformat}
bq. It is to differentiate normal requests and unit-test-case requests. It is
generally not a good idea to have unit test code mingled in the source code.
But in our case, as the cactus in-container unit test is still in its early
stage, It cannot set the request attributes in the webRequest. Although it has
a servletRequestWrapper, but the attributes set through that are not visible to
the source code request. To successfully conduct unit test, we have to do some
extra work in the source code to cooperate the unit test code.
Sorry, my question was not clear. I mean: how does the servlet behave when this
parameter is included? The previous version played a similar game, but the unit
test functionality was (intended to be) disabled in the "real" version (the
http Connector is not started). Since the proxy's purpose is (partially)
authentication, I'm curious how this affects its operation in production, as
the current trick isn't disabled in that case.
bq. These two files are also needed for normal functionality. User need to edit
these two files for their purpose anyway. I don't think leaving them blank and
having some default testing value make much difference.
While it doesn't affect operation, it's not a readable example. It makes more
sense to move this pathological example into the test dir, and put something
more comprehensible in the conf dir.
> Add Tomcat support to hdfsproxy
> -------------------------------
>
> Key: HADOOP-5023
> URL: https://issues.apache.org/jira/browse/HADOOP-5023
> Project: Hadoop Core
> Issue Type: Improvement
> Components: contrib/hdfsproxy
> Reporter: Kan Zhang
> Assignee: zhiyong zhang
> Attachments: HADOOP-5023.patch, HADOOP-5023.patch, HADOOP-5023.patch
>
>
> We plan to add Tomcat support to hdfsproxy since Tomcat has good production
> support at Yahoo.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
