Running the all config from a clean check out and build is fine (at
least for booting). Running the testsuite does give an error when
booting the all configuration (during jboss-all-config-tests target),
but logs indicate is due to port 1098 already being in use. Saw the
same on the
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-remoting-testsuite-1.4?log=log20060405030135
TESTS FAILEDAnt Error Message:/services/cruisecontrol/work/scripts/build-jboss-remoting.xml:96: The following error occurred while executing this line:
Just want to bring to your attention 2 important issues
A) Planning any JBossAS release is quite hard due to complexity and the simple
reason that developer availability is mostly unknown (work on primary projects,
training, consulting, vacations, traveling, conferences, sudden disappearances,
Various Issues
--
- Breakage of jboss commons. Is this the right time, or should do for 4.0.5.
Aren't we already overloaded? Who How?
- Which thirdparty libs can be removed? So far I've noticed apache-wss4j
apache-jaxme.
- JBoss.Net is not even included in the docs/examples
When we started work on 4.0.4 we had 300+ issues ahead of us, now after
2 candidate releases we are down to around 80, which is quite an
achievement, but still a significant amount of work is left for the
final (GA) release.
The current target date is 26th/April which includes Easter and is just
Forgot also to mention that thing that should go in the admin guide
should be linked from this JIRA task:
http://wiki.jboss.org/wiki/Wiki.jsp?page=404UpgradeIssues
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting
Actually the correct link:
http://jira.jboss.com/jira/browse/JBAS-2821
Forgot also to mention that thing that should go in the admin
guide should be linked from this JIRA task:
---
This SF.Net email is sponsored by xPML, a
Ok, so I just found a bug in JIRA, the correct links are:
Compatibility
http://jira.jboss.com/jira/secure/IssueNavigator.jspa?mode=hiderequestId=12310487view=rnotes
Doco
http://jira.jboss.com/jira/secure/IssueNavigator.jspa?mode=hiderequestId=12310486view=rnotes
On Wed, 2006-04-05 at 12:16 +0100,
And even that is broken!
It shows displaying 1..20 of 37 but there is no link to view the
others :-)
Just remove the view=rnotes
On Wed, 2006-04-05 at 12:22 +0100, Adrian Brock wrote:
Ok, so I just found a bug in JIRA, the correct links are:
Compatibility
From: Adrian Brock
Let's keep the process simple please.
I already:
1) Describe the change on the JIRA task
2) Update and the relevant WIKI page and link it on the JIRA task
3) Mark the JIRA task as requiring a doco change
I am not going to update an arbitrary number of web pages when
It turned out that build clean then build all doesn't copy
jboss-remoting.jar to the server build lib directory causing this
error. I overcome the issue by copying the above jar to
build/output/jboss-5.0.0.alpha/server/all/lib directory.
Now I see the error reported on cruise control but only on
JBossXB is going to stay at CR3 unless WebServices request new urgent fixes.
Dimitris Andreadis wrote:
Various Issues
--
- Breakage of jboss commons. Is this the right time, or should do for 4.0.5. Aren't
we already overloaded? Who How?
- Which thirdparty libs can be removed? So
Documenation is also done by all.
On Wed, 2006-04-05 at 09:55 -0400, Tom Elrod wrote:
The 'all' target and the 'most' target are the same except that 'all'
calls 'modules-all' and 'most' calls 'modules-most'. Anyone know the
difference between the two (modules-all and modules-most)?
Hany
javadoc is generated in all, but its completely upto the module all
target definition to make this distinction. The all target should depend
on most and add to it.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Tom Elrod
Sent: Wednesday, April 05,
The minimal server log shows a time gap of 60 sec before starting the
shutdown, and the all config starts before this is complete.
http://cruisecontrol.jboss.com/cc/artifacts/jboss-4.0-testsuite/20060405
072327/build/output/jboss-4.0.4.GA/server/minimal/log/server.log
2006-04-05 07:44:00,223
An undeployed class loader should probably still delegate to its parent
if it does not have a repository?
-Original Message-
From: Adrian Brock
Sent: Wednesday, April 05, 2006 9:42 AM
To: Scott M Stark
Cc: Rajesh Rajasekaran; QA; jboss-development@lists.sourceforge.net
Subject:
The minimal shutdown is very sensative to the implementation details of
the server because there is no jmx invoker in this config. The shutdown
relies on the behavior of a service undeployment calling System.exit so
JBAS-3050 has likely changed how this behaves. I don't remember why this
service
The problem is that ExitOnShutDown.java
invokes exit() from stopService()
this means the new code thinks the deployment thread is busy,
because exit() never returns.
I'll make stopService() fork a thread.
On Wed, 2006-04-05 at 11:21 -0500, Scott M Stark wrote:
The minimal shutdown is very
Very interesting Mr Bond...
new Thread(new Runnable()
{
public void run()
{
System.exit(0);
}
}, ExitOnShutdown).start();
Can't do that either, because this cannot load a class from the
undeployed classloader. :-)
2006-04-05 17:36:57,751
On Wed, 2006-04-05 at 11:44 -0500, Scott M Stark wrote:
An undeployed class loader should probably still delegate to its parent
if it does not have a repository?
Agreed. Reflection didn't work either.
I've changed the minimal config to have
attribute name=StopTimeOut0/attribute
to temporarily
I'll create a jira issue for the class loader behavior.
-Original Message-
From: Adrian Brock
Sent: Wednesday, April 05, 2006 10:16 AM
To: Scott M Stark
Cc: Rajesh Rajasekaran; QA; jboss-development@lists.sourceforge.net
Subject: RE: jboss-4.0-testsuite Build Failed
On Wed,
The deployment is destroyed before the classloader.
It is just that it left a thread lying around referencing the
classloader.
On Wed, 2006-04-05 at 12:33 -0500, Scott M Stark wrote:
I do have to question why the class loader is destroyed before all
deployments are though. I'll look into that
I do have to question why the class loader is destroyed before all
deployments are though. I'll look into that as part of the JBAS-3063
issue.
-Original Message-
From: Scott M Stark
Sent: Wednesday, April 05, 2006 10:24 AM
To: Adrian Brock
Cc: Rajesh Rajasekaran; QA;
jboss.net module can't be removed due to the wonderful cvs modules
behavior. I don't want a jboss-4.0.xv2 module alias definition.
- JBoss.Net is not even included in the docs/examples now.
Should it be removed from the 4.0.x module checkout?
Right. Every jira issue with a documentation check box should have an
entry section in the highlights section of the release notes. Every jira
issue with a compatibility check box should have an entry in the
compatibility section.
-Original Message-
From: Adrian Brock
Sent: Wednesday,
We have to separate out jbossxb because of the jbossws dependency. This
is already being integrated via a binary and that is all that needs to
be done for the 4.0.4.GA release. All of the other breakup of common is
a future thing.
- Breakage of jboss commons. Is this the right time, or
should
The 'all' target and the 'most' target are the same except that 'all'
calls 'modules-all' and 'most' calls 'modules-most'. Anyone know the
difference between the two (modules-all and modules-most)?
Hany Mesha wrote:
It turned out that build clean then build all doesn't copy
Is this (and the tutorial issue) not a
good reason for 1.3.1.CR1?
And then 1 week later, once we have a bug
free release, we just rename (and retag it) as 1.3.1.GA.
From: Ben Wang
Sent: Tuesday, April 04, 2006 8:42
PM
To: jboss-development@lists.sourceforge.net
Cc: QA
Do we guarantee client-server compatibility between different JBoss
revisions?
In other words, is a client using 4.0.1 client jars guaranteed to
connect without problems to a 4.0.4 server?
How about the other way around (4.0.4 client jars to 4.0.1 server )?
How about different minor
Do we guarantee client-server compatibility between different
JBoss revisions?
After JBoss 4.0.2 3.2.8 we try to guarantee interoperability with
previous (4.0.0/4.0.1) versions.
In other words, is a client using 4.0.1 client jars
guaranteed to connect without problems to a 4.0.4 server?
jbossws1.0 should be a final release. I think the only thing holding
back jbossretro from a final release is feedback on the efficacy based
on the current jbossws14 in 4.0.4CR2.
-Original Message-
From: Dimitris Andreadis
Sent: Wednesday, April 05, 2006 3:33 AM
To: jboss-development
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-3.2-testsuite?log=log20060405233748Lbuild.243
BUILD COMPLETE-build.243Date of build:04/05/2006 23:37:48Time to build:49 minutes 24 secondsLast changed:04/05/2006 17:48:26Last log entry:Upgrade to joesnmp
32 matches
Mail list logo
