JBoss daily test results
SUMMARY
Number of tests run: 534
Successful tests: 525
Errors:2
Failures: 7
[time of test: 12 March 2002 6:2 GMT]
[java.version: 1.3.1_
Does the build currently work ? I am getting errors the resource adapter, jdbc local
package...
In StatementInPool, PreparedStatmentInPool, ConnectionInPool... The errors are all
wanting the classes to be declared as abtract as various methods aren't defined.
I've tried under 1.3.1 and 1.4.0,
JBoss daily test results
SUMMARY
Number of tests run: 527
Successful tests: 517
Errors:3
Failures: 7
[time of test: 12 March 2002 5:10 GMT]
[java.version: 1.3.1
JBoss daily test results
SUMMARY
Number of tests run: 534
Successful tests: 525
Errors:2
Failures: 7
[time of test: 12 March 2002 3:44 GMT]
[java.version: 1.3.1
JBoss daily test results
SUMMARY
Number of tests run: 534
Successful tests: 525
Errors:2
Failures: 7
[time of test: 12 March 2002 2:35 GMT]
[java.version: 1.3.1
User: starksm
Date: 02/03/11 18:08:00
Modified:src/resources/security-spec/META-INF jboss.xml
Log:
Fix the entity jndi bindings
Revision ChangesPath
1.5 +23 -27jbosstest/src/resources/security-spec/META-INF/jboss.xml
Index: jboss.xml
===
JBoss daily test results
SUMMARY
Number of tests run: 527
Successful tests: 516
Errors:3
Failures: 8
[time of test: 12 March 2002 1:52 GMT]
[java.version: 1.3.0
User: gregwilkins
Date: 02/03/11 17:50:52
Modified:jetty/src/main/org/mortbay/http HttpContext.java
Log:
Fixed rather embarrasing security problem with security constraints.
A constraint at /my/secret/stuff/* could be bypassed with //my//secret//stuff
The Jetty recommendat
Bugs item #527328, was opened at 2002-03-08 02:16
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=527328&group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 9
Submitted By: Thomas Hamann (thomash76)
Assigne
User: starksm
Date: 02/03/11 17:41:49
Modified:src/main/org/jboss/security/srp SRPService.java
Log:
Support jndi names with subcontexts and cleanup bindings on shutdown
Revision ChangesPath
1.8 +24 -10jbosssx/src/main/org/jboss/security/srp/SRPService.java
User: starksm
Date: 02/03/11 17:40:03
Modified:src/main/org/jboss/naming NonSerializableFactory.java
Log:
Add a rebind that creates intermediate subcontexts.
Revision ChangesPath
1.9 +25 -2 jboss/src/main/org/jboss/naming/NonSerializableFactory.java
Index
I'd just like to add that I had to do a completely clean checkout before I could build
too. That's from CVS just a few minutes before this post.
No combination of "clean" or "clobber" would allow a build from a "cvs update -dP".
_
View th
User: starksm
Date: 02/03/11 17:05:00
Modified:src/main/org/jboss/system ServiceController.java
Log:
Validate that the ctx proxy is not null to avoid NPEs during shutdown
Revision ChangesPath
1.4 +72 -47jboss-system/src/main/org/jboss/system/ServiceController.
JBoss daily test results
SUMMARY
Number of tests run: 527
Successful tests: 515
Errors:4
Failures: 8
[time of test: 12 March 2002 0:52 GMT]
[java.version: 1.3.0
Guys... this is not the right way to do this. This creates a dependency
between the module and the project build module... so the module will
only work inside of that project.
For example, the j2ee module, which is also part of the jboss-website
(for the survey) was failing for this reason.
CHANGE OF VENUE: JBOSS LONDON OPEN HOUSE WEDNESDAY MARCH 13
Come meet Marc Fleury and Sacha Labourey at The Selfridge Hotel (link to
http://www.thistlehotels.com/main/hotel/theselfridge/index.xml), in the
Cleveland Room at 7PM. We previously announced the venue as the London
Marriott Grosvenor Sq
Ok, I just removed the copy of the src/etc dir from the management/build.xml
file and the build works with pruning. I also removed the reference to the
non-existent jsr77.jar from the main build.xml file.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
x
User: starksm
Date: 02/03/11 14:32:02
Modified:jbossbuild.xml
Log:
Remove the reference to the non-existent jsr77.jar
Revision ChangesPath
1.109 +1 -8 build/jboss/build.xml
Index: build.xml
User: starksm
Date: 02/03/11 14:32:31
Modified:.build.xml
Log:
Remove the src/etc copy
Revision ChangesPath
1.3 +1 -6 jboss-management/build.xml
Index: build.xml
===
RCS file: /c
Bugs item #528697, was opened at 2002-03-11 22:22
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=528697&group_id=22866
Category: JBossCMP
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Hunter Hillegas (hunterhillegas)
Ass
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
HERE ARE THE LAST 50 LINES OF THE LOG FILE
[xdoclet] Generating output for 'org.j
--- Scott M Stark <[EMAIL PROTECTED]> wrote:
> The automatic build is no longer failing. What empty directory
> are you seeing that is required for building?
>
I think it is still failing - the last one worked because I did a
full checkout - but it will fail again at the next one, because it
wi
The automatic build is no longer failing. What empty directory
are you seeing that is required for building?
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: "Bill Burke" <[EMAIL PROTECTED]>
To: "Jboss-Dev"
Ok...I feel like I'm in the twilight zone now. I just got a fresh checkout from CVS
and the updated Proxies and ProxyCompiler classes from 3/11/2002 are not there. Plus
the VerifierError is reintroduced into my system. I tried restoring the proxy.compiler
package from my recycle bin, but no luc
_not_ pruning empty directories? Is it me, or is the non-existence of an
empty directory an exceedingly silly reason for a build to fail?
-danch
Bill Burke wrote:
> make sure you're not pruning empty directories. Otherwise, you won't be
> able to build.
>
> I bet this is why the automatic bui
Hi,
I can stop it pruning empty directories - is that the correct
solution though - there's usually been an little text file explaining
the purpose of the directory.
Chris
--- Bill Burke <[EMAIL PROTECTED]> wrote:
> make sure you're not pruning empty directories. Otherwise, you
> won't be
> ab
make sure you're not pruning empty directories. Otherwise, you won't be
able to build.
I bet this is why the automatic build is failing. Anybody know how to fix
the automatic build?
Bill
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://
Hi,
I had posted this on jboss-user list. Since I got no answer I am posting
it here again.
I see when I used Jboss 3, it created 101 bean instances
(standardjboss.xml has 100) when the first client request was made. So
how do I control the minimum and maximum number of instances. Strange
thing
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
HERE ARE THE LAST 50 LINES OF THE LOG FILE
[xdoclet] Generating output for 'org.j
Bill,
works for me after a clean co
I hit this link on lubega.com (the 'do a full CVS checkout' thing - does this really
work??)and the end of the last compilelog now says
...
cvs co - return code = 0
[ Mon Mar 11 18:16:17 GMT 2002 ] jboss cronjob_build.sh started
building jboss
bui
for a relation service.
*
+ * Revisions:
+ * 20020311 Adrian Brock:
+ *
+ * Fixed setRole for external MBean and exception handling
+ * EmptyStack exception in purging
+ * Unregistered mbeans should only contain relation mbeans
+ * Unregister notifications not working after
User: ejort
Date: 02/03/11 10:21:32
Modified:src/main/test/compliance/relation
RelationServiceTestCase.java
RelationSupportTestCase.java
Log:
Relation Service Fixes, not applied to 1.0 yet
Revision ChangesPath
1.3
fails in management module.
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
HERE ARE THE LAST 50 LINES OF THE LOG FILE
[xdoclet] Generating output for 'org.j
That is not what njar is being used for, and it is not working
with security policies. The full name under deploy is being
used to establish security policies. Another solution I'm
looking at involing the custom class loader policy handling
suggested by Adrian requires neither a custom protocol or
Bugs item #527328, was opened at 2002-03-08 02:16
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=527328&group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 9
Submitted By: Thomas Hamann (thomash76)
Assigne
The reason njar was introduced in the first place was so that we could apply
a security policy to the classes that are in a nested jar. Scott seems to
have had some success doing that with njar and the sun jdk.
Regards,
Hiram
>From: "marc fleury" <[EMAIL PROTECTED]>
>To: "Hiram Chirino" <[EM
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
HERE ARE THE LAST 50 LINES OF THE LOG FILE
[xdoclet] Generating output for 'org.j
On 2002.03.11 07:57:16 -0500 marc fleury wrote:
> i haven't really delved into the njar stuff but at this point it seems we
> are complicating the problem with it.
>
> can't we just unjar all the jars that arrive with web stuff and be done
> with
> problem?
I think the problem is not with the js
On 2002.03.11 08:00:39 -0500 marc fleury wrote:
> |The DeploymentInfo only knows about the local copy of exactly the
> package
> |we started with. Everything else is njar urls. The njar handler
> conceals
>
> the njar feels like a hack at this point but again i haven't looked into
> it.
>
> re
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
HERE ARE THE LAST 50 LINES OF THE LOG FILE
[xdoclet] Generating output for 'org.j
|The DeploymentInfo only knows about the local copy of exactly the package
|we started with. Everything else is njar urls. The njar handler conceals
the njar feels like a hack at this point but again i haven't looked into it.
remember when we were talking of unpacking everyone (or at least the
i haven't really delved into the njar stuff but at this point it seems we
are complicating the problem with it.
can't we just unjar all the jars that arrive with web stuff and be done with
problem?
yes it will break the jsp if you don't have a filesystem but let's face it
running a webserver wit
Whoops,
Little fast on the commit trigger there ... should be all in CVS now.
Sorry for the inconvenience,
Jan
[EMAIL PROTECTED] wrote:
> Bugs item #528449, was opened at 2002-03-11 11:32
> You can respond by visiting:
> http://sourceforge.net/tracker/?func=detail&atid=376685&aid=528449&grou
User: janb
Date: 02/03/11 04:17:44
Added: jetty/src/main/org/mortbay/http/handler
ContentEncodingHandler.java
Log:
First checkin
Revision ChangesPath
1.1
contrib/jetty/src/main/org/mortbay/http/handler/ContentEncodingHandle
User: janb
Date: 02/03/11 04:17:45
Added: jetty/src/main/org/mortbay/util StringBufferWriter.java
Log:
First checkin
Revision ChangesPath
1.1 contrib/jetty/src/main/org/mortbay/util/StringBufferWriter.java
Index: StringBufferWriter.java
User: janb
Date: 02/03/11 04:14:54
Added: jetty/src/main/org/mortbay/util Loader.java
Log:
New file.
Revision ChangesPath
1.1 contrib/jetty/src/main/org/mortbay/util/Loader.java
Index: Loader.java
Bugs item #528449, was opened at 2002-03-11 11:32
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=528449&group_id=22866
Category: Build System
Group: v3.0 Rabbit Hole
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Thomas Hamann (thomash76)
Bugs item #528449, was opened at 2002-03-11 12:32
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=528449&group_id=22866
Category: Build System
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Hamann (thomash76)
Assign
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
HERE ARE THE LAST 50 LINES OF THE LOG FILE
private TimeStatistic mActivation = new
Christoph,
I checked in the fix to JBoss today, so next time you refresh your tree
you should pick it up.
Tschüss!
Jan
> you are too fast form me to answer (not to speak of the time-zone difference
> which makes me sleep and dream the sweetest things while your resolve that
> problem) ;-)
>
>
Bugs item #527328, was opened at 2002-03-08 11:16
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=527328&group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 9
Submitted By: Thomas Hamann (thomash76)
Assigne
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
HERE ARE THE LAST 50 LINES OF THE LOG FILE
private TimeStatistic mActivation = new
Hi David,
The problem I found is in MBeanProxy, I didn't have
time to look at it over the weekend.
Maybe JBossMX's MBeanProxy should be used? It doesn't
have this problem. But I haven't looked too closely
at either implementation.
I can fix it if you like. I've still got to check
the entire sour
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
HERE ARE THE LAST 50 LINES OF THE LOG FILE
private TimeStatistic mActivation = new
Bugs item #527328, was opened at 2002-03-08 02:16
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=527328&group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 9
Submitted By: Thomas Hamann (thomash76)
Assigne
Jan,
you are too fast form me to answer (not to speak of the time-zone difference
which makes me sleep and dream the sweetest things while your resolve that
problem) ;-)
Yes I guess the code was that
if( ... extractWars || !isDirectory(...)) {
Jar.extractblablabla
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
HERE ARE THE LAST 50 LINES OF THE LOG FILE
private TimeStatistic mActivation = new
Bugs item #527328, was opened at 2002-03-08 11:16
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=527328&group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
>Priority: 9
Submitted By: Thomas Hamann (thomash76)
Assign
59 matches
Mail list logo
