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: "Jaso
The major issue with Log4j that I have is size... it is huge. Commons is
very small. If Log4j has a 20k footprint (or smaller) for client usage an
dprovided a simple method to disable logging, then I would see no need for
Commons Logging.
Generally I am a pro-"just use log4j", but our own re
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 muc
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 PR
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, Octobe
Bugs item #620514, was opened at 2002-10-08 18:18
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=620514&group_id=22866
Category: JBossMQ
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Steve Wolfangel (swolfangel)
Assigne
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.]
Patches item #620459, was opened at 2002-10-08 21:16
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376687&aid=620459&group_id=22866
Category: JAWS (inactive)
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Christian Sprajc (totmacherr)
Assigne
...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
__
Bugs item #620440, was opened at 2002-10-08 16:37
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=620440&group_id=22866
Category: CatalinaBundle
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Don Laidlaw (dlaidlaw)
Assign
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 --
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
___
Jboss-dev
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) pla
> 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 PROTECTED]
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
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
> Colem
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 j
On Tue, 8 Oct 2002, Matt Munz wrote:
> When I first saw XMBean XML, I assumed that 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 is not cle
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
_
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
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 2002.10.08
Bugs item #620254, was opened at 2002-10-08 09:31
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=620254&group_id=22866
Category: JBossTX
Group: v3.0 Rabbit Hole
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Marko Strukelj (mstruk)
Assigne
Bugs item #620254, was opened at 2002-10-08 09:31
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=620254&group_id=22866
Category: JBossTX
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Marko Strukelj (mstruk)
>Assigned to
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
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 n
JMX gurus,
When I first saw XMBean XML, I assumed that 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 in any way in
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
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
Bugs item #620293, was opened at 2002-10-08 15:18
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=620293&group_id=22866
Category: JBossMQ
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Bernd Zeitler (frito)
Assigned to: N
Bugs item #620262, was opened at 2002-10-08 16:44
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=620262&group_id=22866
Category: JBossCX
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=detail&atid=376685&aid=620254&group_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=detail&atid=376685&aid=620254&group_id=22866
Category: JBossTX
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Marko Strukelj (mstruk)
Assigned to:
Bugs item #608790, was opened at 2002-09-13 07:41
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=608790&group_id=22866
Category: JBossMX
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 4
Submitted By: Chris Kimpton (kimptoc)
Assigned to:
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 transactio
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 o
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
>
>
>
=
==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.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
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
=
==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
=
==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
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 a
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 o
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 ;)
>
> http://subversion.tigr
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.
=
==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
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
keeps
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 anno
=
==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
53 matches
Mail list logo
