RE: [JBoss-dev] House keeping in JIRA - bug reports
by Dimitris Andreadis
Absence of a component could be avoided if we could remove this option
from the user that enters the report (so there is somebody assigned to
it, even if it is the wrong person) but it doesn't seem possible in
JIRA.
I don't think it is bad to have unscheduled reports, as long as there is
periodic review to schedule tasks. It is equally bad to use the next
release as a dumping ground and move around deferred tasks from release
to release.
I totally agree proper/periodic review is needed to categorize the
importance of tasks. There was a proposal by Andrig to do this monthly
but we didn't follow up properly.
> -----Original Message-----
> From: jboss-development-bounces(a)lists.jboss.org
> [mailto:jboss-development-bounces@lists.jboss.org] On Behalf
> Of Adrian Brock
> Sent: Friday, September 22, 2006 5:56 PM
> To: jboss-development
> Subject: [JBoss-dev] House keeping in JIRA - bug reports
>
> Until JBoss-4.0.4 I made a regular check of JIRA using two
> queries. After that release as an experiment I stopped doing
> it to see what kind of state we would be in by the 4.0.5 release.
>
> Bugs without fix versions:
> http://jira.jboss.com/jira/secure/IssueNavigator.jspa?mode=hid
> e&requestId=12310183
>
> All bugs should either be
> * assigned to the currently being worked on release
> * deferred to a later release
> * closed as not bugs or incomplete description
>
> Bugs should never be left unscheduled.
>
> Bugs without components:
> http://jira.jboss.com/jira/secure/IssueNavigator.jspa?mode=hid
> e&requestId=12310202
>
> Which probably means that nobody has even looked at them.
>
> It is very important that for each release we have analysed
> all bugs and decided their importance.
>
> 61 bugs that are not scheduled (i.e. importance undetermined)
> 11 bugs without components (not even validated at the most
> basic level)
>
> is not good!
>
> Just choosing one at random (the oldest one with "affects
> 4.0.4") falls into both categories. There is no evidence it
> was ever looked at:
> http://jira.jboss.com/jira/browse/JBAS-3406
> It was raised on the 20th of July (over two months ago).
>
> Obviously, the user doesn't consider a MalformedObjectName
> exception as telling him the format is invalid nor has he
> read the javadoc for that class which links him to valid
> query formats. :-)
>
> So this is obviously a trival "user friendly" bug where an
> invalid name should forward to a page explaining the
> ObjectName format.
> --
> xxxxxxxxxxxxxxxxxxxxxxxxxxx
> Adrian Brock
> Chief Scientist
> JBoss a division of Red Hat
> xxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
>
20 years
httpd and tomcatClustering gives 404 during redeploy.
by Jean-frederic Clere
Hi,
I am trying to find a way to improve the behaviour of mod_proxy httpd
and JBossAS when an application is reployed.
For the moment in MainDeployer.java we have something like:
redeploy()
{
undeploy();
deploy();
}
Due to this Tomcat doesn't know that the webapp is being redeployed and
between the first undeploy() and end of deploy() is will return 404.
It is possible to add a ContainerListener in Tomcat but the only things
we get are removeChild and addChild events. It is possible to send a
message to httpd to tell that the context of the webapp is not available
in the node (to try to use another node of the cluster).
I think that to make it clean we need to add a start_redeploy and
end_redeploy event in Tomcat and modify MainDeployer and
AbstractWebDeployer so that the redeploy event could reach the Tomcat
classes.
Comments?
Cheers
Jean-Frederic
20 years
