Hi,
> I think I've found the problems.
>
> Problem 1
> -
> A does a normal loadClass() - no lock on UCL
> it gets past synchronise into the main routine
> B does a loadClassInternal() - locks the UCL
> A reaches unsynchronise, aquires the reentrantLock, releases
> itself as the curre
I am running into an exception when trying to display the thread page from the
forums. I do not see the decorations, but I do see the main content, and I
have this exception in the logs:
01:50:13,851 WARN [Jetty] WARNING: GET
/forums/thread.jsp?forum=62&thread=16341 HTTP/1.1
java.lang.NullP
One of our guys came up with this target in our build file:
You can pre-compile JSPs, if its compile errors you're worried about.
hth
dim
- Original Message -
From: "Jason Dillon" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, May 30, 2002 4:14 PM
Subject: [JBoss-dev] Possible to use Jikes to compile Jsp with Jetty?
If so, can som
If so, can some one explain this to me. Jsp compiles are killing us on the
website, hard to test new versions...
--jason
___
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon
been integrated into 3.0?
--jason
___
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
___
Jboss-devel
This time in org.jboss.test.jmsra.test.RaTopicUnitTestCase
21:05:22,375 INFO [MainDeployer] Successfully completed deployment of
package:
file:/D:/usr/JBoss3.0/jboss-all/testsuite/output/lib/jmsra.jar
21:10:23,781 WARN [TxCapsule] Transaction XidImpl [FormatId=257,
GlobalId=succu
bus-si//573, B
We are already using the UCL and ULR from 3.1. I am seeing occasional
hangs of the stress testcases. Here is a trace of the
org.jboss.test.jca.test.CachedConnectionBankStressTestCase
with two request threads hung in the ULR. This is on a dual processor
box.
"RMI TCP Connection(285)-172.17.66.54"
will 3.1 UCL and ULR solve this? Try it.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Jason
> Dillon
> Sent: Wednesday, May 29, 2002 11:12 PM
> To: [EMAIL PROTECTED]
> Subject: [JBoss-dev] 3.0 and ClassCircularityError
>
>
> I do not belive we
I do not belive we should make this final until we have resolve these
issues... I am now seeing this with jetty classes:
22:07:15,690 ERROR [STDERR] java.lang.ClassCircularityError:
org/mortbay/http/ChunkableInputStream
22:07:15,690 ERROR [STDERR] at
org.mortbay.http.HttpConnection.(HttpC
You people are all insane. The size is small, and can be made even smaller if
it really needs to be. Having light weight clients does not mean we must
drop all client-side logging or hack together our own ultra-minimal logging
framework or revert to System.out/printStackTrace garbage.
Log4j
|If I am remember well, we never use log4j directly, right? but a wrapper
|class? What I meant was: couldn't we make the wrapper not require log4j by
|default.
clearly please no log4j on the client, test or no test on our part
please no... let's keep it lightweight,
marcf
|
|
|___
Looks like Jetty in JBoss 3.0 (perhaps 3.1 too) will start servicing requests
before a web application has been fully deployed, leaving the deployment and
the jetty in a very odd state of funk where nothing works.
--jason
___
Don't m
Number of tests run: 606
Successful tests: 605
Errors:0
Failures: 1
[time of test: 29 May 2002 18:47 GMT]
[java.version: 1.3.1]
[java.vendor: Apple Computer, Inc.]
[ja
Number of tests run: 606
Successful tests: 606
Errors:0
Failures: 0
[time of test: 29 May 2002 18:59 GMT]
[java.version: 1.3.1_03]
[java.vendor: Sun Microsystems Inc.]
Number of tests run: 734
Successful tests: 720
Errors:9
Failures: 5
[time of test: 30 May 2002 2:36 GMT]
[java.version: 1.3.0]
[java.vendor: IBM Corporation]
[java.vm.
They seem to have dropped log4j-core.jar in 1.2.2 as I
couldn't find it. The log4j-boot.jar is probably the same thing.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: "Jason Dillon" <[EMAIL PROTECTED]>
To:
Number of tests run: 741
Successful tests: 727
Errors:9
Failures: 5
[time of test: 30 May 2002 1:5 GMT]
[java.version: 1.3.0]
[java.vendor: IBM Corporation]
[java.vm.v
> Yes. I agree that we need to have tools to debug our stuff. My problem is
> that log4j is only "used" for debugging but in reality it means that that
> all beans in production now must have log4j on the client side.
This is not true, log4j is used to indicate errors and warnings as well.
> It
> Why do you want it out? You must have had a reason to send the
> email. Can
> you explain what your pain was and perhaps we can find a better
> solution to
> it (other than ditching log4j on the client).
Yes. I agree that we need to have tools to debug our stuff. My problem is
that log4j is o
With dynamic proxies and client side interceptors there is JBoss code
on both side. We just need to run even if log4j is not present on
the client side. There is no reason to ban log4j use on code that
may show up in an external client because that code may in fact
be running in the same VM as the
> Log4j is our logging infrastructure on the *server* side, yes. But the
> client side isn't *your* infrastructure but the user's infrastructure. What
> if the user wants to use another log4j version? etc. our client side code
> mustn't be so intrusive.
JBoss code is running on both sides. We do
> Log4j is our logging infrastructure, server and client side...
> why would we
> want to remove that?
?!!???
Log4j is our logging infrastructure on the *server* side, yes. But the
client side isn't *your* infrastructure but the user's infrastructure. What
if the user wants to use another log4j
What branch? I have cleaned up this output on HEAD significantly.
--jason
On Wednesday 29 May 2002 10:27 am, marc fleury wrote:
> the deployers throw 3 or 4 exceptions that are a repeat when a simple error
> occurs.
>
> Does anyone want to get in there and REMOVE ALL LOGGING of exceptions, it
Note, we should be using log4j-core.jar on the client, to reduce the
footprint. I have not checked to see if this is the case.
--jason
On Wednesday 29 May 2002 06:31 am, Hiram Chirino wrote:
> Log4j on the client side is the only way to trace/debug problems with
> client side code. In the ca
Log4j is our logging infrastructure, server and client side... why would we
want to remove that?
--jason
On Wednesday 29 May 2002 03:26 am, Sacha Labourey wrote:
> Jason,
>
> Which is the part you don't understand?
>
> Cheers,
>
>
> Sacha
>
> > Um... what?
> >
> >
Really notifyAll only introduces some thread context
switching overhead when there are many threads waiting, but
it generally provides more robust code. See the examples in
Doug Lea's book.
> But
> // This release() must be inside the synchronization block on the
> classloader
> // to avoid
adrian simplify,
ANY entry in a load should synchronize and monothread. It's the chicken
approach to the problem. I am recommending the "nuclear" bomb approach we
seem to move in frog leaps creating new locks at each step. The cache sync
was done this way,
marcf
|-Original Message-
|
Hi,
Ordering the currentThread and ULR didn't fix the problem I was seeing.
This might still be a valid fix?
I tried Dave Smith's -Xdebug, but I couldn't get it to deadlock in
this mode after about 10 testsuite runs :-(
I think I've found the problems.
Problem 1
-
A does a normal loadC
Bugs item #562082, was opened at 2002-05-29 20:51
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=562082&group_id=22866
Category: JBossServer
Group: v2.4 (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason Gerard (sf_sucks)
Assigned to:
Bugs item #560816, was opened at 2002-05-26 22:35
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=560816&group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Frank Seidinger (seidinger)
A
Bugs item #560816, was opened at 2002-05-26 22:35
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=560816&group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Frank Seidinger (seidinger)
A
Bugs item #560816, was opened at 2002-05-26 22:35
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=560816&group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Frank Seidinger (seidinger)
A
Patches item #562036, was opened at 2002-05-29 21:19
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376687&aid=562036&group_id=22866
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Marius Kotsbak (mkotsbak)
Assigned to: Nobody/Ano
Bugs item #559441, was opened at 2002-05-23 01:21
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=559441&group_id=22866
Category: JBossCX
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Stephen Coy (scoy)
Assigned to: Nobod
Bugs item #562004, was opened at 2002-05-29 14:11
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=562004&group_id=22866
Category: JBossCMP
Group: CVS HEAD
Status: Open
Resolution: None
Priority: 5
Submitted By: Justin Casp (jcasp)
Assigned to: Nobody/Anon
Bugs item #560816, was opened at 2002-05-26 22:35
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=560816&group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Frank Seidinger (seidinger)
A
the deployers throw 3 or 4 exceptions that are a repeat when a simple error
occurs.
Does anyone want to get in there and REMOVE ALL LOGGING of exceptions, it
makes jboss look completely broken.
At most keep the uttermost one in Main
Any takers?
marcf
x
Marc Fleury, Ph.D
Preside
Bugs item #560816, was opened at 2002-05-26 22:35
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=560816&group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Frank Seidinger (seidinger)
Bugs item #555381, was opened at 2002-05-13 03:15
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=555381&group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
>Status: Pending
>Resolution: Postponed
Priority: 5
Submitted By: Laurence Smith (lasmith
Bugs item #560816, was opened at 2002-05-26 13:35
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=560816&group_id=22866
>Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Frank Seidinger (seidinger)
Assi
Bugs item #561981, was opened at 2002-05-29 10:00
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=561981&group_id=22866
Category: JBossMQ
Group: None
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Chris McCafferty (mccaffc)
Assigned to
Bugs item #561981, was opened at 2002-05-29 18:00
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=561981&group_id=22866
Category: JBossMQ
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris McCafferty (mccaffc)
Assigned to: Nobody/An
Bugs item #561964, was opened at 2002-05-29 09:37
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=561964&group_id=22866
Category: None
Group: v3.0 Rabbit Hole
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Chris McCafferty (mccaffc)
Assign
Bugs item #561964, was opened at 2002-05-29 17:37
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=561964&group_id=22866
Category: None
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris McCafferty (mccaffc)
Assigned to:
Bugs item #561546, was opened at 2002-05-28 07:43
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=561546&group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Marius Kotsbak (mkotsbak)
As
Bugs item #561546, was opened at 2002-05-28 16:43
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=561546&group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
>Status: Open
>Resolution: Invalid
Priority: 5
Submitted By: Marius Kotsbak (mkotsbak)
As
Bugs item #539379, was opened at 2002-04-04 10:36
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=539379&group_id=22866
Category: JBossCMP
Group: v3.0 Rabbit Hole
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Matthias Bohlen (mattes3)
Assigne
Title: Nachricht
... ok, they sort of
reacted ...
Evaluation
x@x 2002-05-28
We will revisit this decision (from bug 4406709).
563 votes is not
enough! Let them state
Evaluation
x@x 2002-05-28
We will revisit this decision (from bug 4406
Giju Thomson wrote:
> Hi ,
> I have been a avid user of Jboss . I have seen some unwanted
> creation of objects(bean) during ejb creation and during
> findByPrimaryKey . and these object are being garbaged collection soon .
> I think this needs to be looked at .
Why should this be looked
Log4j on the client side is the only way to trace/debug problems with client
side code. In the case of JBossMQ, 1/2 of all the work is done on the
client side! It's super important to keep the ability to trace client side
code.
Regards,
Hiram
>From: "Sacha Labourey" <[EMAIL PROTECTED]>
>Re
Hi,
Ok, always become the current thread before synchronizing on the ULR
sorts the ordering.
Will this introduce any other problems?
Regards,
Adrian
>From: "Bordet, Simone" <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>To: <[EMAIL PROTECTED]>
>Subject: RE: [JBoss-Dev] DeployServiceUnitTestC
|If that's the case, then I think there is no other choice than
|using the reentrant lock for every method of ULR, so that the code
|is wrapped into a try/finally (acquire/release).
|Adrian, can you try the above to see if it works ?
Woke up this morning, and was thinking that we should make the
Hi,
> The hang is not predictable, but it is mostly on the
> RaTopicUnitTestCase.
> Trying to dump the threads crashes the VM, but below is the start
> of one of the dumps. It appears to be a deadlock in the
> UnifiedLoaderRepository.
>
> Looking at the code, there might be an ordering problem
I am still seeing a hang with the 3_0 branch. Start java with the
-Xdebug option. This will show where the lock is ...
On Wed, 2002-05-29 at 05:36, Adrian Brock wrote:
> Hi Scott,
>
> The hang is not predictable, but it is mostly on the RaTopicUnitTestCase.
> Trying to dump the threads crashes
Bugs item #561852, was opened at 2002-05-29 11:52
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=561852&group_id=22866
Category: None
Group: None
>Status: Deleted
Resolution: None
Priority: 5
Submitted By: Mikael Löwenadler (milowe)
Assigned to: Nobody/A
Bugs item #561546, was opened at 2002-05-28 16:43
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=561546&group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Marius Kotsbak (mkotsbak)
Assi
Bugs item #561546, was opened at 2002-05-28 16:43
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=561546&group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Marius Kotsbak (mkotsbak)
Assi
Bugs item #561546, was opened at 2002-05-28 16:43
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=561546&group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Marius Kotsbak (mkotsbak)
Assi
Jason,
Which is the part you don't understand?
Cheers,
Sacha
> Um... what?
>
> --jason
___
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://de
Bugs item #561752, was opened at 2002-05-29 02:44
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=561752&group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
>Status: Pending
>Resolution: Accepted
Priority: 5
Submitted By: Scott M Stark (starksm)
hi,
On Tue, 2002-05-28 at 23:43, Jason Dillon wrote:
> Um... what?
you can't have an "ejb client" contacting jboss w/o having log4j in your
classpath. i second sacha's bug report on this; i can't see a reason why
a client should be forced to have that in its classpath.
the whole situation on
Bugs item #561852, was opened at 2002-05-29 11:52
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=561852&group_id=22866
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mikael Löwenadler (milowe)
Assigned to: Nobody/Anony
Hi Scott,
The hang is not predictable, but it is mostly on the RaTopicUnitTestCase.
Trying to dump the threads crashes the VM, but below is the start
of one of the dumps. It appears to be a deadlock in the
UnifiedLoaderRepository.
Looking at the code, there might be an ordering problem between
s
Hi , I have been a avid user of Jboss . I have seen some unwanted creation of objects(bean) during ejb creation and during findByPrimaryKey . and these object are being garbaged collection soon . I think this needs to be looked at .
Cheers ThomsonDo You Yahoo!?
Yahoo! - Official partner of 2002
Number of tests run: 604
Successful tests: 602
Errors:0
Failures: 2
[time of test: 29 May 2002 0:29 GMT]
[java.version: 1.3.1]
[java.vendor: Apple Computer, Inc.]
[jav
66 matches
Mail list logo
