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 jo
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-developm
> 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 serve
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 versio
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
Sub
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
jboss-remoting.jar
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
> shoul
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: Wednesda
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?
>
--
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-devel
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'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 W
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
0
to temporarily workaround the issue.
>
> >
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
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 sensa
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 co
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
> Subjec
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
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
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)?
>
>
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
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 m
> 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 page
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
> http://jira.jboss.com/jira/secure
Ok, so I just found a bug in JIRA, the correct links are:
Compatibility
http://jira.jboss.com/jira/secure/IssueNavigator.jspa?mode=hide&requestId=12310487&view=rnotes
Doco
http://jira.jboss.com/jira/secure/IssueNavigator.jspa?mode=hide&requestId=12310486&view=rnotes
On Wed, 2006-04-05 at 12:16 +01
You can already get this information from JIRA.
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
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 groundbreaki
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 language
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-seam-testsuite?log=log20060405063615
TESTS FAILEDAnt Error Message: /services/cruisecontrol/work/scripts/build-jboss-seam-testsuite.xml:138: The following error occurred while executing this line: /services/cruisecontrol/wor
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 no
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
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,
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-remoting-testsuite-1.5?log=log20060405034845
TESTS FAILEDAnt Error Message: /services/cruisecontrol/work/scripts/build-jboss-remoting.xml:96: The following error occurred while executing this line: /services/cruisecontrol/wo
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: /services/cruisecontrol/wo
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-cache-testsuite?log=log20060405022505
TESTS FAILEDAnt Error Message: /services/cruisecontrol/work/scripts/build-JBossCache.xml:86: The following error occurred while executing this line: /services/cruisecontrol/work/scripts/
35 matches
Mail list logo
