geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Trunk Builds
Date Wed, 01 Jul 2009 07:23:53 GMT

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<david_jencks@yahoo.com> 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<kevan.miller@gmail.com

>>>> >
>>>> 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
>>>>>
>>>

Mime
View raw message