Hi Marina,
I think the confusing part is that it *was* working yesterday, and
*today* it was not. It was
not a new test that has never run,
but a new test that coincidentally broke today. So it was good that
the test was added just in time to highlight the regression from
yesterday making it easier to reproduce. :)
Ideally, a broken test (even if it started getting broken the same day)
should not be added, however, the admin console has been severely
lacking a test and was under a lot of pressure to get one in. Since
the fix came quickly and helped in reproducing the fix, I think it was
good that the test was left in. Marina, sorry for the inconvenience.
:(
Thanks Jason for the test, and Jeanfrancois for the fix!
Ken
Marina Vatkina wrote:
Anissa,
May be I'm confused. Is it a separate QL or a general GF QL?
If it's a separate QL, then I'm just confused, and the GF QL is failing
for a completely different reason.
If it's a GF QL, then I'd expect any new test to be enabled only after
it passes (it's ok to have a test that fails and can be run
stand-alone).
Regards,
-marina
Anissa Lam wrote:
Marina Vatkina wrote:
Hi Anissa,
Anissa Lam wrote:
Hi Marina,
I don't think i agree with you.
If there is QL failure in say 'admin' or 'security' or 'web
container', do you remove that or comment out that part of
quicklook ? Why Admin Console should be different ?
You are expected not to check in the code that breaks the QL, right?
Yes. Thats what is expected by everyone. We didn't break QL. The
test shows that there is bug in the system that causes QL to fail.
Your saying of : *'a QL that is guarantee to report failures' *is not
true at all.
It reports failure because there is a regression in the system. If we
were able to turn on the QL yesterday, then someone will see that
whatever the change they put in is causing Admin Console to fail and we
can avoid this .
Agree. Where I disagree, is the point of adding a test *before* it can
pass.
Sorry, I don't get this. We were always able to run this QL test
until this afternoon. Because of this QL test, we are able to catch
the problem in the web container. Jeanfrancois just said that he
found the problem now, and he is putting in the fix soon. Once his
fix is in, QL will pass. So, what is wrong with our test ?
Thanks
Anissa.
This is what QL is for.
Yes.
thanks,
-marina
thanks
Anissa
Marina Vatkina wrote:
Anissa Lam wrote:
I will say no. Why do you want to turn off the test ?
So that others can easily see if they cause any regressions?
It is a valid
test and the system is indeed has
problem. There is no way to bring up the admin console now.
That's why we have an open bug. But having a QL that is guarantee to
report failures is very confusing...
thanks,
-marina
Jan is looking into the issue and think that
may be related to the Grizzly
integration.
thanks
Anissa.
Marina Vatkina wrote:
Anissa,
Can we turn off Admin Console QL until you find the fix?
thanks,
-marina
Anissa Lam wrote:
Thanks to Jason, Admin Console QL is now turned on. If you update
your workspace, your QL run will also include admin console QL.
As of now, admin console QL is failing because there is problem in the
system. We can't access the login page and thus cannot bring up the
console. It sure does the job :)
An issue has been filed,
https://glassfish.dev.java.net/issues/show_bug.cgi?id=6131
Hopefully we will be able to catch this kind of issue sooner now that
the test is in place.
thanks
Anissa.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: dev-help@glassfish.dev.java.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: dev-help@glassfish.dev.java.net