See inline.
Simon
ant elder wrote:
On 9/7/07, Luciano Resende <[EMAIL PROTECTED]> wrote:
On 9/7/07, Simon Nash <[EMAIL PROTECTED]> wrote:
I'm a bit concerned with this default as it would cause conflicts
if I have a Web app server active on port 8080 while I'm running a
test that uses either of these environments.
Yes, using 8080 would conflict with existing web app servers running
locally and on the build environment. So I'd prefer some different
default, like 8085
Changing this would be changing the default for samples as well as the unit
tests, do we really want to do that? Could we have a setter so unit tests
can set whatever default they like? Also right now 8085 is only the default
for WS things anything else using http picks up the 8080 default from the
Jetty or Tomcat ServletHost impl.
Ideally we would be testing the samples as part of the build as well as
running the itests. (There has been previous discussion on this.) So the
same issue of port conflicts would arise for samples in a build or test
environment.
I don't think we should just provide a setter and expect every itest to
call it. This would be burdensome, error-prone, and wouldn't work if
samples were run as part of the build. Instead, I think we should have
some way to globally configure a different default for the ServletHost
setting. For example, we could use a Java system property that can
be set using the pom configuration of the maven surefire plugin. This
would allow one setting for itests (and samples run during the build),
and another setting for samples run by the user.
Anyway, the actual default value is slightly tangential to what i was asking
about - removing the BASE_URI from the Axis2 binidng - from whats been said
i'll take it its ok to do that (as long as the issues with failing tests can
be resolved).
I think the only linkage is that we shouldn't remove the hardcoded
value until we have an agreed solution that allows samples run outside
the build to use port 8080 and the build to use some other port such as
8085. As soon as we can agree and implement a suitable way to do this,
I am fine with removing the hardcoded value.
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
