You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Kevan Miller <ke...@gmail.com> on 2009/06/25 17:00:15 UTC
Trunk Builds
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
Re: Trunk Builds
Posted by David Jencks <da...@yahoo.com>.
On Jul 2, 2009, at 11:36 AM, Jarek Gawor wrote:
> On Wed, Jul 1, 2009 at 6:51 PM, David Jencks<da...@yahoo.com>
> wrote:
>>
>> On Jul 1, 2009, at 11:04 AM, Jarek Gawor wrote:
>>
>>> David,
>>>
>>> I'm trying to make things work and behave the same for ejb-based web
>>> services as for servlet-based web services. I have a similar
>>> security
>>> tests to jaxws-ejb-sec for servlet-based web services - see
>>> jaxws-war-sec. Take a look at /basicAllowGet example in web.xml. It
>>> has one http-method specified (POST) and auth-method is configured
>>> to
>>> BASIC. That allows me to perform GET on the service without any
>>> security but POST request will require BASIC auth. So if that's how
>>> are things working for web-based services I would like to have the
>>> same behavior for ejb-based services.
>>
>> I'm not very happy with what we can configure now. With a web app,
>> you can
>> have lots of security constraints but IIUC for ejb ws you can only
>> have one.
>> So with a single web security constraint, say you restrict POST to
>> require
>> CONFIDENTIAL and auth. That means that non-POST requests are
>> completely
>> unconstrained both for transport and for auth. In a web app you
>> can have
>> more constraints so that e.g. there's still transport guarantee.
>>
>> If we imitate this with ejb constraints but only allow a single
>> constraint,
>> then adding a http method into the mix mostly unsecures everything
>> else. I
>> don't think this is a good idea. I think there are 2 reasonable
>> options:
>>
>> 1. if we only allow a single constraint, only grant the permissions
>> from
>> that constraint.... everything else is prohibited. This is nearly
>> the
>> opposite of what servlet constraints do. This is pretty easy to
>> implement.
>> 2. allow full web-like multiple security-constraint elements
>> although we'd
>> ignore the role-constraint mapping since the ejb security ought to
>> be more
>> meaningful. This is more complicated to implement, but might not
>> be exactly
>> difficult.
>>
>
> I don't understand why a single security constraint in web should be
> handled differently then a single security constraint in ejb. Bottom
> line is that we do want to provide an option for unsecure access for
> GETs to retrieve the wsdl and secure access for all other HTTP
> methods. The issue is mainly with the javax.xml.ws.Service API where
> you have to pass a service wsdl url to create an instance of it but
> there is no easy way to specify what authentication method and/or
> credentials to use to retrieve that wsdl. And once you have the
> Service instance there is an easy way to configure the
> credentials/authentication method on the port object for the
> invocation (the POST, PUT, etc. requests).
>
Since there are an infinite set of http methods now, you can't secure
all non-GET requests with one servlet 2.5 security constraint. I'm
not sure if there's a syntax for servlet 3.0 web.xml to exclude GET
requests but apparently you can do it on servlets with annotations.
So I don't know how to produce this effect for POJO ws but its pretty
easy for ejb ws with two permissions.
If the only use case is the binary choice between
-- secure all requests with transport guarantee and authentication
-- secure all non-GET requests with transport guarantee and
authentication but allow all GET requests with no transport guarantee
or authentication
then I think a flag in our xml would be more appropriate than what we
have now.
Are there other choices?
thanks
david jencks
> Jarek
Re: Trunk Builds
Posted by Jarek Gawor <jg...@gmail.com>.
On Wed, Jul 1, 2009 at 6:51 PM, David Jencks<da...@yahoo.com> wrote:
>
> On Jul 1, 2009, at 11:04 AM, Jarek Gawor wrote:
>
>> David,
>>
>> I'm trying to make things work and behave the same for ejb-based web
>> services as for servlet-based web services. I have a similar security
>> tests to jaxws-ejb-sec for servlet-based web services - see
>> jaxws-war-sec. Take a look at /basicAllowGet example in web.xml. It
>> has one http-method specified (POST) and auth-method is configured to
>> BASIC. That allows me to perform GET on the service without any
>> security but POST request will require BASIC auth. So if that's how
>> are things working for web-based services I would like to have the
>> same behavior for ejb-based services.
>
> I'm not very happy with what we can configure now. With a web app, you can
> have lots of security constraints but IIUC for ejb ws you can only have one.
> So with a single web security constraint, say you restrict POST to require
> CONFIDENTIAL and auth. That means that non-POST requests are completely
> unconstrained both for transport and for auth. In a web app you can have
> more constraints so that e.g. there's still transport guarantee.
>
> If we imitate this with ejb constraints but only allow a single constraint,
> then adding a http method into the mix mostly unsecures everything else. I
> don't think this is a good idea. I think there are 2 reasonable options:
>
> 1. if we only allow a single constraint, only grant the permissions from
> that constraint.... everything else is prohibited. This is nearly the
> opposite of what servlet constraints do. This is pretty easy to implement.
> 2. allow full web-like multiple security-constraint elements although we'd
> ignore the role-constraint mapping since the ejb security ought to be more
> meaningful. This is more complicated to implement, but might not be exactly
> difficult.
>
I don't understand why a single security constraint in web should be
handled differently then a single security constraint in ejb. Bottom
line is that we do want to provide an option for unsecure access for
GETs to retrieve the wsdl and secure access for all other HTTP
methods. The issue is mainly with the javax.xml.ws.Service API where
you have to pass a service wsdl url to create an instance of it but
there is no easy way to specify what authentication method and/or
credentials to use to retrieve that wsdl. And once you have the
Service instance there is an easy way to configure the
credentials/authentication method on the port object for the
invocation (the POST, PUT, etc. requests).
Jarek
Re: Trunk Builds
Posted by David Jencks <da...@yahoo.com>.
On Jul 1, 2009, at 11:04 AM, Jarek Gawor wrote:
> David,
>
> I'm trying to make things work and behave the same for ejb-based web
> services as for servlet-based web services. I have a similar security
> tests to jaxws-ejb-sec for servlet-based web services - see
> jaxws-war-sec. Take a look at /basicAllowGet example in web.xml. It
> has one http-method specified (POST) and auth-method is configured to
> BASIC. That allows me to perform GET on the service without any
> security but POST request will require BASIC auth. So if that's how
> are things working for web-based services I would like to have the
> same behavior for ejb-based services.
I'm not very happy with what we can configure now. With a web app,
you can have lots of security constraints but IIUC for ejb ws you can
only have one. So with a single web security constraint, say you
restrict POST to require CONFIDENTIAL and auth. That means that non-
POST requests are completely unconstrained both for transport and for
auth. In a web app you can have more constraints so that e.g. there's
still transport guarantee.
If we imitate this with ejb constraints but only allow a single
constraint, then adding a http method into the mix mostly unsecures
everything else. I don't think this is a good idea. I think there
are 2 reasonable options:
1. if we only allow a single constraint, only grant the permissions
from that constraint.... everything else is prohibited. This is
nearly the opposite of what servlet constraints do. This is pretty
easy to implement.
2. allow full web-like multiple security-constraint elements although
we'd ignore the role-constraint mapping since the ejb security ought
to be more meaningful. This is more complicated to implement, but
might not be exactly difficult.
thoughts?
thanks
david jencks
>
> Jarek
>
> On Wed, Jul 1, 2009 at 3:23 AM, David Jencks<da...@yahoo.com>
> wrote:
>>
>>
>> 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
>>
Re: Trunk Builds
Posted by Jarek Gawor <jg...@gmail.com>.
David,
I'm trying to make things work and behave the same for ejb-based web
services as for servlet-based web services. I have a similar security
tests to jaxws-ejb-sec for servlet-based web services - see
jaxws-war-sec. Take a look at /basicAllowGet example in web.xml. It
has one http-method specified (POST) and auth-method is configured to
BASIC. That allows me to perform GET on the service without any
security but POST request will require BASIC auth. So if that's how
are things working for web-based services I would like to have the
same behavior for ejb-based services.
Jarek
On Wed, Jul 1, 2009 at 3:23 AM, David Jencks<da...@yahoo.com> wrote:
>
>
> 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
>
Re: Trunk Builds
Posted by David Jencks <da...@yahoo.com>.
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<da...@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
>>>>>
>>>
Re: Trunk Builds
Posted by David Jencks <da...@yahoo.com>.
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.
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<da...@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
>>>>
>>
Re: Trunk Builds
Posted by Jarek Gawor <jg...@gmail.com>.
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 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.
Jarek
On Tue, Jun 30, 2009 at 5:04 AM, David Jencks<da...@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<ke...@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
>>>
>
Re: Trunk Builds
Posted by David Jencks <da...@yahoo.com>.
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<ke...@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
>>
Re: Trunk Builds
Posted by Jarek Gawor <jg...@gmail.com>.
Shawn,
Looks like my copy of dojo-release-1.1.1-mini.zip was outdated and
files were wrapped in an extra "dojo" directory. Once I updated it the
extra "dojo" directory disappeared. I updated the DOJO_BASE in
ConfirmMessageTag.java.
Thanks,
Jarek
On Tue, Jul 7, 2009 at 3:38 AM, Shawn Jiang<ge...@gmail.com> wrote:
> Sorry, Are we using the same trunk build ? I downloaded the tomcat trunk
> build here:
>
> http://people.apache.org/builds/geronimo/server/binaries/trunk/20090703/geronimo-tomcat6-javaee5-2.2-SNAPSHOT-bin.zip
>
> When accessing http://localhost:8080/dojo/dojo/dojo.js , I got it's
> content:
>
> /*
> Copyright (c) 2004-2008, The Dojo Foundation All Rights Reserved.
>
> Available via Academic Free License >= 2.1 OR the modified BSD license.
> see: http://dojotoolkit.org/license for details
> */
>
> (function(){var _1=null;if((_1||(typeof
> djConfig!="undefined"&&djConfig.scopeMap))&&(typeo
>
> When accessing http://localhost:8080/dojo/dojo/dojo/dojo.js, I got this:
>
> HTTP Status 404
>
> I also tried to revert ConfirmMessageTag.java to dojo/dojo/dojo.js from
> dojo/dojo/dojo/dojo.js. The dialog poped up and the test suite passed.
> So , can anyone else help verify this ?
>
> On Tue, Jul 7, 2009 at 1:09 AM, Jarek Gawor <jg...@gmail.com> wrote:
>>
>> Shawn,
>>
>> I recently modified ConfirmMessageTag.java so that it points to the
>> right locations for dojo resources. It used to point to
>> http://localhost:8080/dojo/dojo/dojo.js (which does not work) but now
>> points to http://localhost:8080/dojo/dojo/dojo/dojo.js (which does
>> work). That made the confirmation box to display again. The
>> confirmation box does display now when you use the web browser and
>> follow the steps of the test but somehow it fails in our automatic
>> tests. The test does pass for me when I execute it on my machine in
>> the same way as the automatic tests do... so that's why I thought it
>> was a timing issue. But there might be something else going on, I'm
>> not sure.
>>
>> Jarek
>>
>> On Fri, Jul 3, 2009 at 10:53 AM, Shawn Jiang<ge...@gmail.com> wrote:
>> >
>> >
>> > On Fri, Jul 3, 2009 at 2:53 AM, Jarek Gawor <jg...@gmail.com> wrote:
>> >>
>> >> Shawn,
>> >>
>> >> The one failure in console/advanced on Tomcat is caused by fixing that
>> >> prompting issue in the console. I'm hoping it's just a timing issue
>> >
>> > It's not a timing issue. This is caused by a modification on
>> > ConfirmMessageTag.java recently .
>> >
>> > After that change, dojo.js can't be found so that the prompting dialog
>> > can't be display anymore.
>> >
>> > Revert the bvt change and update the code
>> >
>> > private static final String DOJO_BASE = "/dojo/dojo"
>> >
>> > to
>> >
>> > private static final String DOJO_BASE = "/dojo"
>> >
>> > can fix this.
>> >>
>> >> since its takes a bit of time to load all the Dojo stuff for the first
>> >> time. So I just increased the wait time for the window to show up in
>> >> that test.
>> >>
>> >> Jarek
>> >>
>> >> On Wed, Jul 1, 2009 at 9:31 PM, Shawn Jiang<ge...@gmail.com> wrote:
>> >> > I can't recreate the same console/advanced failure in my local
>> >> > machine.
>> >> > But I do find another console testsuite bug and filed a JIRA:
>> >> > https://issues.apache.org/jira/browse/GERONIMO-4720 (patch
>> >> > provided)
>> >> > The failure of enterprise-testsuite/sec-tests is related to
>> >> > "run-as" propagation from a servlet to another servlet. I'm looking
>> >> > into
>> >> > it and will provide a patch.
>> >> > On Thu, Jun 25, 2009 at 11:58 PM, Jarek Gawor <jg...@gmail.com>
>> >> > 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<ke...@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
>> >> >> >
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Shawn
>> >> >
>> >
>> >
>> >
>> > --
>> > Shawn
>> >
>
>
>
> --
> Shawn
>
Re: Trunk Builds
Posted by Shawn Jiang <ge...@gmail.com>.
Sorry, Are we using the same trunk build ? I downloaded the tomcat trunk
build here:
*
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090703/geronimo-tomcat6-javaee5-2.2-SNAPSHOT-bin.zip
*
When accessing http://localhost:8080/*dojo/dojo/*dojo.js , I got it's
content:
/*
Copyright (c) 2004-2008, The Dojo Foundation All Rights Reserved.
Available via Academic Free License >= 2.1 OR the modified BSD license.
see: http://dojotoolkit.org/license for details
*/
(function(){var _1=null;if((_1||(typeof
djConfig!="undefined"&&djConfig.scopeMap))&&(typeo
When accessing http://localhost:8080/*dojo/dojo/dojo*/dojo.js, I got this:
HTTP Status 404
I also tried to revert ConfirmMessageTag.java to dojo/dojo/dojo.js from
dojo/dojo/dojo/dojo.js. The dialog poped up and the test suite passed.
So , can anyone else help verify this ?
On Tue, Jul 7, 2009 at 1:09 AM, Jarek Gawor <jg...@gmail.com> wrote:
> Shawn,
>
> I recently modified ConfirmMessageTag.java so that it points to the
> right locations for dojo resources. It used to point to
> http://localhost:8080/dojo/dojo/dojo.js (which does not work) but now
> points to http://localhost:8080/dojo/dojo/dojo/dojo.js (which does
> work). That made the confirmation box to display again. The
> confirmation box does display now when you use the web browser and
> follow the steps of the test but somehow it fails in our automatic
> tests. The test does pass for me when I execute it on my machine in
> the same way as the automatic tests do... so that's why I thought it
> was a timing issue. But there might be something else going on, I'm
> not sure.
>
> Jarek
>
> On Fri, Jul 3, 2009 at 10:53 AM, Shawn Jiang<ge...@gmail.com> wrote:
> >
> >
> > On Fri, Jul 3, 2009 at 2:53 AM, Jarek Gawor <jg...@gmail.com> wrote:
> >>
> >> Shawn,
> >>
> >> The one failure in console/advanced on Tomcat is caused by fixing that
> >> prompting issue in the console. I'm hoping it's just a timing issue
> >
> > It's not a timing issue. This is caused by a modification on
> > ConfirmMessageTag.java recently .
> >
> > After that change, dojo.js can't be found so that the prompting dialog
> > can't be display anymore.
> >
> > Revert the bvt change and update the code
> >
> > private static final String DOJO_BASE = "/dojo/dojo"
> >
> > to
> >
> > private static final String DOJO_BASE = "/dojo"
> >
> > can fix this.
> >>
> >> since its takes a bit of time to load all the Dojo stuff for the first
> >> time. So I just increased the wait time for the window to show up in
> >> that test.
> >>
> >> Jarek
> >>
> >> On Wed, Jul 1, 2009 at 9:31 PM, Shawn Jiang<ge...@gmail.com> wrote:
> >> > I can't recreate the same console/advanced failure in my local
> machine.
> >> > But I do find another console testsuite bug and filed a JIRA:
> >> > https://issues.apache.org/jira/browse/GERONIMO-4720 (patch
> provided)
> >> > The failure of enterprise-testsuite/sec-tests is related to
> >> > "run-as" propagation from a servlet to another servlet. I'm looking
> >> > into
> >> > it and will provide a patch.
> >> > On Thu, Jun 25, 2009 at 11:58 PM, Jarek Gawor <jg...@gmail.com>
> 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
> >> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > Shawn
> >> >
> >
> >
> >
> > --
> > Shawn
> >
>
--
Shawn
Re: Trunk Builds
Posted by Jarek Gawor <jg...@gmail.com>.
Shawn,
I recently modified ConfirmMessageTag.java so that it points to the
right locations for dojo resources. It used to point to
http://localhost:8080/dojo/dojo/dojo.js (which does not work) but now
points to http://localhost:8080/dojo/dojo/dojo/dojo.js (which does
work). That made the confirmation box to display again. The
confirmation box does display now when you use the web browser and
follow the steps of the test but somehow it fails in our automatic
tests. The test does pass for me when I execute it on my machine in
the same way as the automatic tests do... so that's why I thought it
was a timing issue. But there might be something else going on, I'm
not sure.
Jarek
On Fri, Jul 3, 2009 at 10:53 AM, Shawn Jiang<ge...@gmail.com> wrote:
>
>
> On Fri, Jul 3, 2009 at 2:53 AM, Jarek Gawor <jg...@gmail.com> wrote:
>>
>> Shawn,
>>
>> The one failure in console/advanced on Tomcat is caused by fixing that
>> prompting issue in the console. I'm hoping it's just a timing issue
>
> It's not a timing issue. This is caused by a modification on
> ConfirmMessageTag.java recently .
>
> After that change, dojo.js can't be found so that the prompting dialog
> can't be display anymore.
>
> Revert the bvt change and update the code
>
> private static final String DOJO_BASE = "/dojo/dojo"
>
> to
>
> private static final String DOJO_BASE = "/dojo"
>
> can fix this.
>>
>> since its takes a bit of time to load all the Dojo stuff for the first
>> time. So I just increased the wait time for the window to show up in
>> that test.
>>
>> Jarek
>>
>> On Wed, Jul 1, 2009 at 9:31 PM, Shawn Jiang<ge...@gmail.com> wrote:
>> > I can't recreate the same console/advanced failure in my local machine.
>> > But I do find another console testsuite bug and filed a JIRA:
>> > https://issues.apache.org/jira/browse/GERONIMO-4720 (patch provided)
>> > The failure of enterprise-testsuite/sec-tests is related to
>> > "run-as" propagation from a servlet to another servlet. I'm looking
>> > into
>> > it and will provide a patch.
>> > On Thu, Jun 25, 2009 at 11:58 PM, Jarek Gawor <jg...@gmail.com> 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<ke...@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
>> >> >
>> >
>> >
>> >
>> > --
>> > Shawn
>> >
>
>
>
> --
> Shawn
>
Re: Trunk Builds
Posted by Shawn Jiang <ge...@gmail.com>.
On Fri, Jul 3, 2009 at 2:53 AM, Jarek Gawor <jg...@gmail.com> wrote:
> Shawn,
>
> The one failure in console/advanced on Tomcat is caused by fixing that
> prompting issue in the console. I'm hoping it's just a timing issue
It's not a timing issue. This is caused by a modification on
ConfirmMessageTag.java recently .
After that change, dojo.js can't be found so that the prompting dialog
can't be display anymore.
Revert the bvt change and update the code
private static final String DOJO_BASE = "/dojo/dojo"
to
private static final String DOJO_BASE = "/dojo"
can fix this.
>
> since its takes a bit of time to load all the Dojo stuff for the first
> time. So I just increased the wait time for the window to show up in
> that test.
>
> Jarek
>
> On Wed, Jul 1, 2009 at 9:31 PM, Shawn Jiang<ge...@gmail.com> wrote:
> > I can't recreate the same console/advanced failure in my local machine.
> > But I do find another console testsuite bug and filed a JIRA:
> > https://issues.apache.org/jira/browse/GERONIMO-4720 (patch provided)
> > The failure of enterprise-testsuite/sec-tests is related to
> > "run-as" propagation from a servlet to another servlet. I'm looking
> into
> > it and will provide a patch.
> > On Thu, Jun 25, 2009 at 11:58 PM, Jarek Gawor <jg...@gmail.com> 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<ke...@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
> >> >
> >
> >
> >
> > --
> > Shawn
> >
>
--
Shawn
Re: Trunk Builds
Posted by Jarek Gawor <jg...@gmail.com>.
Shawn,
The one failure in console/advanced on Tomcat is caused by fixing that
prompting issue in the console. I'm hoping it's just a timing issue
since its takes a bit of time to load all the Dojo stuff for the first
time. So I just increased the wait time for the window to show up in
that test.
Jarek
On Wed, Jul 1, 2009 at 9:31 PM, Shawn Jiang<ge...@gmail.com> wrote:
> I can't recreate the same console/advanced failure in my local machine.
> But I do find another console testsuite bug and filed a JIRA:
> https://issues.apache.org/jira/browse/GERONIMO-4720 (patch provided)
> The failure of enterprise-testsuite/sec-tests is related to
> "run-as" propagation from a servlet to another servlet. I'm looking into
> it and will provide a patch.
> On Thu, Jun 25, 2009 at 11:58 PM, Jarek Gawor <jg...@gmail.com> 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<ke...@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
>> >
>
>
>
> --
> Shawn
>
Re: Trunk Builds
Posted by Shawn Jiang <ge...@gmail.com>.
If the test is wrong, tomcat run-as propagation logic must have bug because
Tomcat testsuite with the same case passed.
On Thu, Jul 2, 2009 at 9:53 AM, David Jencks <da...@yahoo.com> wrote:
>
> On Jul 1, 2009, at 6:31 PM, Shawn Jiang wrote:
>
> I can't recreate the same console/advanced failure in my local machine.
> But I do find another console testsuite bug and filed a JIRA:
>
> https://issues.apache.org/jira/browse/GERONIMO-4720 (patch provided)
>
> The failure of enterprise-testsuite/sec-tests is related to
> "run-as" propagation from a servlet to another servlet. I'm looking into
> it and will provide a patch.
>
>
> The run-as propagation from servlet to servlet is not really specified in
> the servlet spec and I may have changed it in jetty7 after talking with Ron
> Monzilla the sun security spec guy. IIRC jetty7 interprests run-as to apply
> to the target servlet in a dsipatch whether or not the servlets are in the
> same web app. IIRC the previous behavior was that run-as was only applied
> in a cross-context dispatch. So most likely the test is wrong.
>
> thanks
> david jencks
>
>
> On Thu, Jun 25, 2009 at 11:58 PM, Jarek Gawor <jg...@gmail.com> 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<ke...@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
>> >
>>
>
>
>
> --
> Shawn
>
>
>
--
Shawn
Re: Trunk Builds
Posted by David Jencks <da...@yahoo.com>.
On Jul 1, 2009, at 6:31 PM, Shawn Jiang wrote:
> I can't recreate the same console/advanced failure in my local
> machine. But I do find another console testsuite bug and filed a
> JIRA:
>
> https://issues.apache.org/jira/browse/GERONIMO-4720 (patch provided)
>
> The failure of enterprise-testsuite/sec-tests is related to "run-as"
> propagation from a servlet to another servlet. I'm looking into it
> and will provide a patch.
The run-as propagation from servlet to servlet is not really specified
in the servlet spec and I may have changed it in jetty7 after talking
with Ron Monzilla the sun security spec guy. IIRC jetty7 interprests
run-as to apply to the target servlet in a dsipatch whether or not the
servlets are in the same web app. IIRC the previous behavior was that
run-as was only applied in a cross-context dispatch. So most likely
the test is wrong.
thanks
david jencks
>
> On Thu, Jun 25, 2009 at 11:58 PM, Jarek Gawor <jg...@gmail.com>
> 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<ke...@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
> >
>
>
>
> --
> Shawn
Re: Trunk Builds
Posted by Shawn Jiang <ge...@gmail.com>.
I can't recreate the same console/advanced failure in my local machine.
But I do find another console testsuite bug and filed a JIRA:
https://issues.apache.org/jira/browse/GERONIMO-4720 (patch provided)
The failure of enterprise-testsuite/sec-tests is related to
"run-as" propagation from a servlet to another servlet. I'm looking into
it and will provide a patch.
On Thu, Jun 25, 2009 at 11:58 PM, Jarek Gawor <jg...@gmail.com> 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<ke...@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
> >
>
--
Shawn
Re: Trunk Builds
Posted by Jarek Gawor <jg...@gmail.com>.
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<ke...@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
>