Bugs item #527328, was opened at 2002-03-08 11:16
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=527328group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 9
Submitted By: Thomas Hamann (thomash76)
Assigned
=
==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 =
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
Bugs item #527328, was opened at 2002-03-08 02:16
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=527328group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 9
Submitted By: Thomas Hamann (thomash76)
Assigned
=
==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 =
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
=
==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 =
Bugs item #527328, was opened at 2002-03-08 11:16
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=527328group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 9
Submitted By: Thomas Hamann (thomash76)
Assigned
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) ;-)
Yes
=
==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 =
Bugs item #528449, was opened at 2002-03-11 12:32
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=528449group_id=22866
Category: Build System
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Hamann (thomash76)
Assigned
Bugs item #528449, was opened at 2002-03-11 11:32
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=528449group_id=22866
Category: Build System
Group: v3.0 Rabbit Hole
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Thomas Hamann (thomash76)
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
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:17:44
Added: jetty/src/main/org/mortbay/http/handler
ContentEncodingHandler.java
Log:
First checkin
Revision ChangesPath
1.1
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:
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
|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
=
==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
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.
remember
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 jsp
=
==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
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 [EMAIL
Bugs item #527328, was opened at 2002-03-08 02:16
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=527328group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 9
Submitted By: Thomas Hamann (thomash76)
Assigned
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
=
==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
fails in management module.
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
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
User: ejort
Date: 02/03/11 10:21:32
Modified:src/main/javax/management/relation RelationService.java
RoleValidator.java
Log:
Relation Service Fixes, not applied to 1.0 yet
Revision ChangesPath
1.5 +29 -9
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
=
==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
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
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]
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
able
_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 build
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
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
--- 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
will
=
==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
Bugs item #528697, was opened at 2002-03-11 22:22
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=528697group_id=22866
Category: JBossCMP
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Hunter Hillegas (hunterhillegas)
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:
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
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
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
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.
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:
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 -47
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 thread
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
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: 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
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:
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
Bugs item #527328, was opened at 2002-03-08 02:16
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=527328group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 9
Submitted By: Thomas Hamann (thomash76)
Assigned
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:
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:
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:
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
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:
59 matches
Mail list logo
