I think the reason is the JVM size that is necessary (-Xmx): it must be
higher probably. Which is why, doing it step by step succeeds: as numerous
steps are already done, the memory is simply exhausted later.
-Message d'origine-
De : [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]De la
One day Subversion will save us from CVS ;)
http://subversion.tigris.org/
-Message d'origine-
De : [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]De la part de
David Jencks
Envoyé : lundi, 7 octobre 2002 23:10
À : [EMAIL PROTECTED]
Objet : Re: [JBoss-dev] README ::
Here is one I got on 3.0 with jdk 1.4.0_01-b03 on windows:
I simply think that the new libs introduce more memory overhead
[xdoclet] Generating output for
'org.jboss.management.j2ee.MessageDrivenBean
' using template file
'jar:file:/J:/CVS_HOME/jboss-3.0/tools/lib/xdoclet.jar!/xd
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
JAVA VERSION DETAILS
java version 1.3.1_03
Java(TM) 2 Runtime Environment, Standard
Scott M Stark wrote:
If you look at the Embedded usage in the JBoss service it is not doing much.
Being able to run off a sar with the minimum elements from tomcat would be
good, but I want to keep the ability to run with a pristine tomcat dist.
Using the normal Tomcat startup code directly
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
JAVA VERSION DETAILS
java version 1.3.1_03
Java(TM) 2 Runtime Environment, Standard
Title: JBoss 3.0.3 Bug: typo in TransactionImpl + trying to change Tx in enlist exception
(using: JBoss-3.0.3-src)
There is a typo in TransactionImpl disassociateCurrentThread(). tx.associateCurrentThread() is called instead of tx.disassociateCurrentThread()
There is another more
SF mail seems hours behind so I don't know if there is a mail in the backlog
from Jason describing the last changes he made to create the jboss-3.0,
jboss-3.2, etc version modules with jboss-all being the main branch.
If there is, this applies to the CVSROOT/modules file version 1.188 which
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
JAVA VERSION DETAILS
java version 1.4.0_01
Java(TM) 2 Runtime Environment, Standard
Using build.sh or build.bat?
--jason
On Tue, 8 Oct 2002, Sacha Labourey wrote:
I think the reason is the JVM size that is necessary (-Xmx): it must be
higher probably. Which is why, doing it step by step succeeds: as numerous
steps are already done, the memory is simply exhausted later.
I hope so... but I do not think there are plans to go away from SourceForge
anytime soon. Perhaps they will start using somthing better sometime this
century...
--jason
On Tue, 8 Oct 2002, Sacha Labourey wrote:
One day Subversion will save us from CVS ;)
I do not think that is possible... could be a problem with 1.4.1. I
verified that clean builds of all projects build correctly with 1.3.1 (using
the new module names that is... did anyone get that email? I sent it hours
agao?).
--jason
On Tue, 8 Oct 2002, Sacha Labourey wrote:
Here is
Looks like mail is slow these days, so I am copying this again...
* * *
I have just verified that all of the branches for the currently active JBoss
versions build correctly out of the box.
I did however need to make some modifications to the CVSROOT/modules file to
make this work correctly
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
JAVA VERSION DETAILS
java version 1.3.1_03
Java(TM) 2 Runtime Environment, Standard
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
JAVA VERSION DETAILS
java version 1.4.0_01
Java(TM) 2 Runtime Environment, Standard
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
JAVA VERSION DETAILS
java version 1.4.0_01
Java(TM) 2 Runtime Environment, Standard
Hi,
_buildmagic:init:
Trying to override old definition of task property
BUILD FAILED
file:/disk/orig/home/lubega/jbossro/jboss-all/build/../tools/etc/buildfragments/tools.ent:29:
taskdef class xdoclet.modules.jmx.JMXDocletTask cannot be found
We've got past the other problems - but
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
JAVA VERSION DETAILS
java version 1.3.1_03
Java(TM) 2 Runtime Environment, Standard
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
JAVA VERSION DETAILS
java version 1.3.1_03
Java(TM) 2 Runtime Environment, Standard
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
JAVA VERSION DETAILS
java version 1.4.0_01
Java(TM) 2 Runtime Environment, Standard
build.bat
-Message d'origine-
De : [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]De la part de
Jason Dillon
Envoye : mardi, 8 octobre 2002 10:37
A : [EMAIL PROTECTED]
Objet : RE: [JBoss-dev] HEAD Build: numerous failure
Using build.sh or build.bat?
--jason
On Tue, 8 Oct
It wasn't with 1.4.1, but with 1.4.0. Maybe that was just my particular
setup. Let's wait to have more user feedback to see if I am the only one
having this issue.
-Message d'origine-
De : [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]De la part de
Jason Dillon
Envoye : mardi, 8
Can you please file two bug reports for these? (please assign them to me if
possible)
If you can supply any kind of example to reproduce the second bug I would
appreciate it. I find it mysterious because the code for LocalTx is
supposed to return connections to the pool only after the
Bugs item #608790, was opened at 2002-09-13 07:41
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=608790group_id=22866
Category: JBossMX
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 4
Submitted By: Chris Kimpton (kimptoc)
Assigned to:
Bugs item #620254, was opened at 2002-10-08 16:31
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=620254group_id=22866
Category: JBossTX
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Marko Strukelj (mstruk)
Assigned to:
Bugs item #620254, was opened at 2002-10-08 16:31
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=620254group_id=22866
Category: JBossTX
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Marko Strukelj (mstruk)
Assigned to:
Bugs item #620262, was opened at 2002-10-08 16:44
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=620262group_id=22866
Category: JBossCX
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Marko Strukelj (mstruk)
Assigned to:
Bugs item #620293, was opened at 2002-10-08 15:18
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=620293group_id=22866
Category: JBossMQ
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Bernd Zeitler (frito)
Assigned to:
Food for thought?
From www.dictionary.com
Modesty - The quality or state of being modest; that lowly temper
which accompanies a moderate estimate of one's own worth
and importance; absence of self-assertion, arrogance, and
presumption; humility respecting
Why don't we set up a CVS testbed somewhere to test CVS changes?
You (editorial 'you') don't (shouldn't) commit changes to code without
thorough testing. Considering what's at risk, it seems to me that CVS
changes should be made even more cautiously.
This project already has too many 'moving
JMX gurus,
When I first saw XMBean XML, I assumed that constructor/ referred to the
constructor for the resource (model object). On a closer look, it appears
that this information (ModelMBeanConstructorInfo) refers only to the
constructor for the MB itself.
Is this information being used
Hi,
They are kept on the lubega server - only...
Chris
- Original Message -
From: Jason Dillon [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, October 08, 2002 10:38 AM
Subject: Re: [JBoss-dev] jboss-all daily clean failed
Hey... where do the scripts that controll the nightly
I had the same problem yesterday.
I've deleted jboss-all (and directory jboss which temporary existed) and
made a new checkout.
Now compilation is fine again.
Regards
Frank
Chris Kimpton wrote:
Hi,
_buildmagic:init:
Trying to override old definition of task property
BUILD FAILED
Bugs item #620254, was opened at 2002-10-08 09:31
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=620254group_id=22866
Category: JBossTX
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Marko Strukelj (mstruk)
Assigned to:
Bugs item #620254, was opened at 2002-10-08 09:31
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=620254group_id=22866
Category: JBossTX
Group: v3.0 Rabbit Hole
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Marko Strukelj (mstruk)
Assigned
Ummm think about it... for CVSROOT changes that would mean being easily
able to get a mirror of the project cvs files (the blah.java,v files),
which AFAIK sourceforge does not enable.
Perhaps a more doable alternative is a list of what to check after CVSROOT
changes.
david jencks
On
I am trying to put together a working example to reproduce the problem.
I will try to go along the following lines: limit connection pool to 2
connections. Create 10 threads that invoke on the server side :
ut.begin();
ds.getConnection();
c.close();
And hope to see the error happen. But I'm
Oops. Missed an important one...
From www.dictionary.com
Ego - An inflated feeling of pride in your superiority to others
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
On Tue, 8 Oct 2002, Matt Munz wrote:
When I first saw XMBean XML, I assumed that constructor/ referred to the
constructor for the resource (model object). On a closer look, it appears
that this information (ModelMBeanConstructorInfo) refers only to the
constructor for the MB itself.
it
The head revision cannot be checked out using the jboss-all module alias any longer.
The jboss-head alias must be used instead. If you successfully wade through the
dump of CVSROOT/module changes and associated mails this is the summary
statement:
- To checkout 3.0 use:
cvs co -r Branch_3_0
How about these definitions:
Aggravation: When somebody fucks up CVS and you waste a whole day of
development.
Annoyance: When somebody posts stupid definitions from www.dictionary.com
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Tom
Coleman
To effectivly test I would need to replicate the entire repository.
--jason
On Tue, 8 Oct 2002, Tom Coleman wrote:
Why don't we set up a CVS testbed somewhere to test CVS changes?
You (editorial 'you') don't (shouldn't) commit changes to code without
thorough testing. Considering
To effectivly test I would need to replicate the entire repository.
FWIW, this could easily be done with rsync, but, as David pointed out,
SF.net probably doesn't allow this level of access to their servers.
- Matt
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL
Juha,
It could be worse -- I could be trying to interpret legal documents ;)
it is not clearly defined which it should refer to in case of MMB. It
might be better defined in JMX 1.2 version of the spec.
Let me reccommend that the resource object constructor info be given a
(defined)
cvs server: [12:47:41] waiting for anoncvs_jboss's lock in
/cvsroot/jboss/jboss-j2ee/src
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Because more people use Tomcat and want to be able to integrate
with existing distributions that they can run standalone. No one has
asked for this with Jetty as yet.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message
Bugs item #620440, was opened at 2002-10-08 16:37
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=620440group_id=22866
Category: CatalinaBundle
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Don Laidlaw (dlaidlaw)
Assigned
...waiting for maximal's lock in /cvsroot/jboss/jboss-j2ee/src
Please somebody remove it.
Thanks,
Bill
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Patches item #620459, was opened at 2002-10-08 21:16
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376687aid=620459group_id=22866
Category: JAWS (inactive)
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Christian Sprajc (totmacherr)
Assigned
Number of tests run: 942
Successful tests: 939
Errors:2
Failures: 1
[time of test: 8 October 2002 15:13 GMT]
[java.version: 1.3.1]
[java.vendor: Apple Computer, Inc.]
Bugs item #620514, was opened at 2002-10-08 18:18
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=620514group_id=22866
Category: JBossMQ
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Steve Wolfangel (swolfangel)
Assigned
If you run the build by hand with -Xmx640m does it function? This is
what build.sh uses. Newer build.bat (coming soon) will also include
this.
--jason
-Original Message-
From: [EMAIL PROTECTED] [mailto:jboss-
[EMAIL PROTECTED]] On Behalf Of Sacha Labourey
Sent: Tuesday, October
It is too bad commons logging does not provide abstractions for a
ContextStack or ContextMap similar to Log4j's NDC and MDC. These are
valuable constructs.
Do you know anyone on the commons logging team?
--jason
-Original Message-
From: [EMAIL PROTECTED] [mailto:jboss-
[EMAIL
Apparently several people have had trouble with jakarta-commons logging,
including xdoclet; this got mentioned on their list:
http://www.qos.ch/logging/thinkAgain.html
Personally I'd be in favor of unwrapping log4j and using it asis. I'm not
convinced that the debug/trace split buys us very
Unless there is a clear advantange to commons over the generalization
Sacha did it is not worth the trouble to switch to an alternate logging
wrapper.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From:
55 matches
Mail list logo
