RE: MC_VDF_WORK branch merge starting tomorrow
by Ryan Campbell
The JEE_TCK branch is now available:
https://svn.jboss.org/repos/jbossas/branches/JEE5_TCK/
> -----Original Message-----
> From: Scott M Stark
> Sent: Friday, September 22, 2006 10:41 AM
> To: JBoss.org development list; QA
> Subject: MC_VDF_WORK branch merge starting tomorrow
>
> We are ready to begin the merge of the MC/VDF work
> (https://svn.jboss.org/repos/jbossas/branches/MC_VDF_WORK/) to trunk
> starting tomorrow. You need to have any outstanding commits in head by
> tonight (2100 GMT), or else migrate to the tck branch
> (https://svn.jboss.org/repos/jbossas/branches/JEE5_TCK/), which will
be
> created from trunk tonight.
>
> I'll start the merge tomorrow and will focus on getting the command
line
> and eclipse projects building. I'll be sending out any unresolvable
> conflicts to the dev list.
>
> In terms of tck work going forward, since we are rewriting the
deployers
> its doubtful that merges between the JEE5_TCK branch and trunk will be
> practical. What I would like is that for any changes to the JEE5_TCK
> branch, you create an issue in the
> http://jira.jboss.com/jira/browse/JBCTS project that includes the
patch
> made (svn diff, eclipse Team->Create Patch) so that whoever is working
> on the associated deployer in trunk can get the change included.
19 years, 10 months
House keeping in JIRA - bug reports
by Adrian Brock
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=hide&requestId...
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=hide&requestId...
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
19 years, 10 months
RE: [JBoss-dev] httpd and tomcatClustering gives 404 during redeploy.
by Dimitris Andreadis
> On Thu, 2006-09-21 at 07:27 -0700, Scott M Stark wrote:
> > Redeploy is not used during a hot-redeploy. The
> URLDeploymentScanner
> > simply does an undeploy/deploy the same as the redeploy in main.
>
> Well URLDeploymentScanner only passes the URL, how do I get
> the information that it is a redeployement in MainDeployer?
I think we could try to change the scanner logic to call redeploy on the
main deployer instead.
19 years, 10 months
