On Jun 30, 2009, at 12:28 PM, David Jencks wrote:
On Jun 30, 2009, at 7:35 AM, Jarek Gawor wrote:
David,
Some errors on the console (or in the logs) are to be expected. The
tests check if for example the service that requires security can be
accessed without security. That should generate some errors and
that's
what the test expects.
As usual I wasn't too clear...
For instance, if I look at concurrent-testsuite/concurrent-basic/
build.log, I see that the build was successful and
....
OUT: Tests run: 20, Failures: 0, Errors: 0, Skipped: 0, Time
elapsed: 316.367 sec
OUT: Results :
OUT: Tests run: 20, Failures: 0, Errors: 0, Skipped: 0
OUT: [INFO] [geronimo:undeploy-module {execution: undeploy-war-as-
moduleId}]
OUT: [INFO] Using non-artifact based module id:
org.apache.geronimo.testsuite/concurrent-web-ear/2.2-SNAPSHOT/ear
....
OUT: Tests run: 16, Failures: 0, Errors: 0, Skipped: 0, Time
elapsed: 0.933 sec
OUT: Results :
OUT: Tests run: 16, Failures: 0, Errors: 0, Skipped: 0
OUT: [INFO] [geronimo:undeploy-module {execution: undeploy-war-as-
moduleId}]
OUT: [INFO] Using non-artifact based module id:
org.apache.geronimo.testsuite/concurrent-ejb-ear/2.2-SNAPSHOT/ear
....
however on the console I'm running the tests from I see
[INFO] concurrent-testsuite/concurrent-basic RUNNING
[INFO] concurrent-testsuite/concurrent-basic FAILURE
(0:20:47.746) Java returned: 1
I don't understand why the test runner thinks the tests failed but I
don't see any failures in the build.log
As to securing ?wsdl access, a while ago I added a feature where the
user can specify which http methods should be secured or not. This
was
supposed to work just like for servlet-based web services. We got a
few queries about this feature and I think we should continue to
support it. In fact, I'm not sure how jaxws-ejb-sec tests would pass
without it.
I was only really looking at jetty here. Previously ?wsdl requests
were serviced before checking transport type and for jetty the
protected methods were ignored. I've changed it so that all
requests have their security checked and that only the http methods
specified are allowed. (I think this is what the tomcat code is
doing also, but I'm not 100% sure). I think this is what you
intended but I find the parameter name "protected methods" a little
confusing.
I fixed IMO all the security problems here and think we should change
the tests for the 2 remaining failures.
The question is whether if the web service requires authentication,
the wsdl requests should too. Previously wsdl requests never required
authentication, just the correct transport guarantee. While this
seemed reasonable when we first wrote this, I no longer think it makes
sense. Currently in the jetty ejb ws if authentication is required
(i.e.an auth method specified) then all requests, both to the ws and
for the wsdl require authentication.
Shall I go ahead and change the testsuite and tomcat ejb ws?
thanks
david jencks
Do you think there's any value in allowing specification of excluded
http methods rather than included methods, as the servlet spec allows?
thanks
david jencks
Jarek
On Tue, Jun 30, 2009 at 5:04 AM, David
Jencks<[email protected]> wrote:
I've worked on GERONIMO-4645, however I'm getting strange results
from
running the testsuite. When I look at build.log for a test bit I
don't see
errors but the console output claims a lot of bits failed.
So hopefully your automated tests won't have this problem and we
can see how
successful I was....
BTW my new code secures access to the ?wsdl for the web service.
This seems
like a good idea to me, WDYT?
thanks
david jencks
On Jun 25, 2009, at 8:58 AM, Jarek Gawor wrote:
Based on running the testsuite yesterday and with fixes committed
last
night I *think* we should be passing all tests on Tomcat and fail
enterprise-testsuite/sec-tests and webservices-testsuite/jaxws-
tests
on Jetty. The webservices-testsuite/jaxws-tests fails because of
GERONIMO-4645. Not sure what's going on with
enterprise-testsuite/sec-tests.
Jarek
On Thu, Jun 25, 2009 at 11:00 AM, Kevan Miller<[email protected]
>
wrote:
A search of emails shows that our last successful automated
build of
trunk
was on May 26th. I know that there have been increasing
frustration with
these recent build issues. We seem to be closing in on getting
these
issues
resolved. I built last night. I built successfully, last night,
but had 7
testsuite failures -- 3 jetty, 4 tomcat.
I think it would do us a lot of good to have a concerted effort
to get
these
final issues resolved. Here are the test failures that I'm seeing:
3 common errors:
[INFO] The following tests failed:
[INFO] * console-testsuite/advanced -
/Users/kevan/geronimo/server/trunk/testsuite/console-testsuite/
advanced/build.log
[INFO] * enterprise-testsuite/sec-tests -
/Users/kevan/geronimo/server/trunk/testsuite/enterprise-
testsuite/sec-tests/build.log
[INFO] * webservices-testsuite/jaxws-tests -
/Users/kevan/geronimo/server/trunk/testsuite/webservices-
testsuite/jaxws-tests/build.log
1 Tomcat unique failure:
[INFO] * web-testsuite/test-tomcat -
/Users/kevan/geronimo/server/trunk/testsuite/web-testsuite/test-
tomcat/build.log
Is this consistent with what others are seeing?
--kevan
