=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
JAVA VERSION DETAILS
java version 1.3.1
Java(TM) 2 Runtime Environment, Standard
I would appreciate deletion of ZOAP as an evidence of my once evil
programming skills ;-)
CGJ
-Ursprüngliche Nachricht-
Von: Jason Dillon [mailto:[EMAIL PROTECTED]]
Gesendet: Dienstag, 23. April 2002 04:31
An: [EMAIL PROTECTED]
Betreff: [JBoss-dev] Are these CVS modules still in use
As a quick work-around while I´m busy today with doing business (buaaeeeh:-(
Patch the java.lang.ClassLoader class ... Either remove the synchronized
keyword from loadClassInternal (should be safe)
or make it protected and remove the synchronized keyword in an overriding
method of
On Tue, 23 Apr 2002, Jung , Dr. Christoph wrote:
As a quick work-around while I´m busy today with doing business (buaaeeeh:-(
Patch the java.lang.ClassLoader class ... Either remove the synchronized
keyword from loadClassInternal (should be safe)
or make it protected and remove the
Change Notes item #547479, was opened at 2002-04-23 12:34
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=381174aid=547479group_id=22866
Category: JBossMX
Group: None
Status: Open
Priority: 5
Submitted By: Juha Lindfors (juhalindfors)
Assigned to: Juha Lindfors
Feature Requests item #547494, was opened at 2002-04-23 03:43
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376688aid=547494group_id=22866
Category: JBossCMP
Group: v3.0 Rabbit Hole
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to:
Start up jboss with the -Xdebug option to the JVM. It will then show the
locking.
On Mon, 2002-04-22 at 21:13, marc fleury wrote:
Unfortunately this VM doesn't show what object it locks on so I can't do the
same analysis I did with Dave Smith's dump, Dave, what VM were you using???
alarik
Of course, it must prepend the JDK-shit, sorry did cutpaste from the
Tool-Doc ...
CGJ
-Ursprüngliche Nachricht-
Von: Holger Engels [mailto:[EMAIL PROTECTED]]
Gesendet: Dienstag, 23. April 2002 11:09
An: [EMAIL PROTECTED]
Betreff: Re: [JBoss-dev] AW: Workaround for CL stuff
On Tue, 23
Actually, it´s more complicated:
Thread 1:
VM detects that it needs bar, calls UCL A.loadClassInternal() and
hence synchronizes on A
Thread 2:
VM detects that it needs foo, calls UCL B.loadClassInternal() and
hence synchronizes on B
Thread 1:
UCL A delegates to
AFAIK, a thread will only release the lock in the closest synchronization
scope.
If you can make sure that the UCL itself is the last lock before entering
ULR, then it
should IMHO work. Since we are not in control of loadClassInternal, but of
loadClass, there is the chance
that this will do as
|AFAIK, a thread will only release the lock in the closest synchronization
|scope.
hence my previous mail
does a double synchronization on the *same* lock release both or not.
marcf
|
|If you can make sure that the UCL itself is the last lock before entering
|ULR, then it
|should IMHO work.
VM Spec 8.14
Suppose that thread T has in fact performed N lock
operations that have not been matched by unlock
operations. The wait method then adds the current thread
to the wait set for the object, disables the current
thread for thread scheduling purposes, and performs N
unlock operations to
David Jencks wrote:
My understanding of Dain's cmp code is that any SQLException will result in
the tx being set rollback only, and basically all work discarded.
In the new local jdbc wrapper, I've done something about as drastic: if
there is any SQLException from any operation, the connection
|VM Spec 8.14
|
|Suppose that thread T has in fact performed N lock
|operations that have not been matched by unlock
|operations. The wait method then adds the current thread
|to the wait set for the object, disables the current
|thread for thread scheduling purposes, and performs N
|unlock
Patches item #547586, was opened at 2002-04-23 09:16
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376687aid=547586group_id=22866
Category: None
Group: v2.4 BETA (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Roland King (rolandking)
Assigned to:
Can we include the DTDs for a release in the binary download?
I keep geting messages asking for the location of the DTDs.
-dain
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Bugs item #547616, was opened at 2002-04-23 15:06
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=547616group_id=22866
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ludovic Claude (ludovicc)
Assigned to:
They are and always have been included in the jboss.jar:
[starksm@banshee jboss-3.0.0RC1]$ jar -tf lib/jboss.jar | grep dtd
org/jboss/metadata/web-app_2_3.dtd
org/jboss/metadata/jboss-web.dtd
org/jboss/metadata/jboss-web_3_0.dtd
org/jboss/metadata/application_1_3.dtd
Bugs item #547616, was opened at 2002-04-23 15:06
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=547616group_id=22866
Category: None
Group: None
Status: Closed
Resolution: Rejected
Priority: 5
Submitted By: Ludovic Claude (ludovicc)
Assigned to:
OK, ran with -Xdebug, and here are the two threads again:
main prio=5 tid=0xc7dd80 nid=0x10b waiting for monitor entry
[0x93fc000..0x93ffdc0]
at java.lang.ClassLoader.loadClass(ClassLoader.java:286)
- waiting to lock 32ff5d8 (a
org.jboss.mx.loading.UnifiedClassLoader)
at
yeah it is teh same see below
|OK, ran with -Xdebug, and here are the two threads again:
|
|main prio=5 tid=0xc7dd80 nid=0x10b waiting for monitor entry
|[0x93fc000..0x93ffdc0]
|at java.lang.ClassLoader.loadClass(ClassLoader.java:286)
|- waiting to lock 32ff5d8 (a
Also (and I don't know what significance this might have), but if I DON'T
spawn another thread I don't get the deadlock. If I DO spawn another
thread, I get the deadlock consistently.
Alarik
___
Jboss-development mailing list
[EMAIL PROTECTED]
Yes I know they are in the jar. I mean we should include a copy in
loose form. It is very useful for developers to be able to easily see
the DTD files.
-dain
Scott M Stark wrote:
They are and always have been included in the jboss.jar:
[starksm@banshee jboss-3.0.0RC1]$ jar -tf
Bugs item #547616, was opened at 2002-04-23 15:06
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=547616group_id=22866
Category: None
Group: None
Status: Closed
Resolution: Rejected
Priority: 5
Submitted By: Ludovic Claude (ludovicc)
Assigned to:
Could be, but the 4 above us all involve major changes to the java language
or probable enormous effort over the entire jdk (excessive memory usage).
At least one (generics) has been under development for years and is
scheduled for 1.5.
david jencks
On 2002.04.23 13:29:29 -0400 Matt Humphrey
That line in MainDeployer refers to a change I put in 2 days ago. I think
you need a clean - or at least you need to recompile the
org.jboss.deployment.DeploymentSorter class.
-Larry
- Original Message -
From: Hunter Hillegas [EMAIL PROTECTED]
To: JBoss Dev [EMAIL PROTECTED]
Sent:
is there anything specific we need to know about building the sources. I
went through the documentation, but it says that everything should build
fine.
D:\Development\jboss\jboss-all\iiop\src\main\org\jboss\proxy\compiler\IIOPSt
ubCo
mpiler.java:252: warning:
I just updated my Branch_3_0 tree and I get this on startup:
10:54:49,833 INFO [MainDeployer] Starting deployment of package:
file:/Users/hunter/Unix/Sources/jboss3/build/output/jboss-3.0.0RC1/lib/jboss
sx.jar
10:54:49,991 ERROR [Server] start failed
java.lang.NoSuchMethodError
at
Dear Friend,
This letter may come to you as a surprise due to the fact that we have
not yet met. The message could be strange but reel if you pay some
attention
to it. I could have notified you about it at least for the sake of your
integrity. Please accept my sincere apologies. In bringing this
I had the same problem with JDK 1.3. If you upgrade to the newest
release of 1.3.1 it goes away.
-dain
Filip Hanik wrote:
is there anything specific we need to know about building the sources. I
went through the documentation, but it says that everything should build
fine.
This seems to be a rmic bug. I tried it yesterday and found out that rmic
doesn't compile the classes if the classpath isn't identical to the output
directory when the -iiop flag is set. I upgraded the jsdk from:
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C)
Java HotSpot(TM)
The modify the build system to release them under build/output/jboss-*/etc/dtd
or something.
--jason
Quoting Dain Sundstrom [EMAIL PROTECTED]:
Yes I know they are in the jar. I mean we should include a copy in
loose form. It is very useful for developers to be able to easily see
the
Hello Dear Friends
This letter is a scam. If you give this guy any personal information,
financial accounts, etc, you'll be sorry.
Regards,
Mac Rinehart, President
Sextant Technology Consulting, Inc
SEXTANT TECHNOLOGY CONSULTING is a trademark of Sextant Technology
Consulting, Inc. Sextant
Jason,
Do you agree that this is a good idea, or are you just suggesting a
course of action for me?
Does anyone dislike the idea of putting them in jboss-whatever/etc/dtd,
or is some other location better? (I really don't have an opinion)
-dain
Jason Dillon wrote:
The modify the build
Do you agree that this is a good idea, or are you just suggesting a
course of action for me?
Both. I would do but don't have time.
Does anyone dislike the idea of putting them in jboss-whatever/etc/dtd,
or is some other location better? (I really don't have an opinion)
either etc/dtd
Sorry to pollute the list but for those interested, check out.
http://www.scamorama.com/
One guy was actually able to get $3 from one of the scammers! Amazing!
-
Anatoly Akkerman
Computer Science Dept.
Courant Institute
We should get the xmbean dtd in there also. Currently it is at
jmx/src/resources/metadata/jboss_xmbean_1_0.dtd. If you can copy it also,
great, otherwise I will try to figure it out.
thanks
david jencks
On 2002.04.23 16:16:58 -0400 Dain Sundstrom wrote:
Jason,
Do you agree that this is a
Patches item #547792, was opened at 2002-04-23 14:26
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376687aid=547792group_id=22866
Category: JBossServer
Group: v2.4 (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Lucas McGregor (lmcgregor)
Assigned
Yes, I have sent mail about this before. Does it barf or just complain?
Do you see the final start message?
Fransico, put in a dummy jacob.properties in default/conf when IIOP
builds to avoid this mess please.
--jason
marc fleury wrote:
he...
did rm on the old stuff
then a CLEAN CO
then
Sacha Labourey wrote:
Hello Jules,
I have recently been thinking a bit about my next iteration on
distributable HttpSessions for JBoss/Jetty.
BTW, does it work?!? I haven't heard you anymore since your last troubles.
I have still not been able to get two JBoss instances to
Are you using the newest version of 1.3.1 from SUN? If not, you need to
upgrade. If you are using 1.4, just ignore me.
Also I thought the jacob.properties was just a warning.
-dain
marc fleury wrote:
he...
did rm on the old stuff
then a CLEAN CO
then build (builds fine btw)
then
righto... I still recommend we disable IIOP by default and just turn it on
with a BIG warning in the service.xml file THAT YOU SHOULD BE USING JDK1.3.1
or JDK1.4, can we keep a service.xml and sort of comment out everything?
that would be useful.
Francisco, can you take care of that?
marcf
This message jacob.properties not found is just a warning
and can be ignored. I am about to commit some changes the will
make it go away.
Francisco
On Tue, 23 Apr 2002, marc fleury wrote:
he...
did rm on the old stuff
then a CLEAN CO
then build (builds fine btw)
then start and I get
On Tue, 23 Apr 2002, Jason Dillon wrote:
Fransico, put in a dummy jacob.properties in default/conf when IIOP
builds to avoid this mess please.
This doesn't work, probably because JacORB is not using the context
classloader to load its resources. Wait a moment, I will commit a
simple change
You may need to upgrade your JDK to build the IIOP stuff, due to an
rmic bug in some older JDK versions. You should not need to upgrade
you JDK to run IIOP. If it is already built then it should run.
(With a jacorb.properties not found warning, which will go away
in a few minutes...)
Are you
Francisco the error that I am seeing
my VM is
java version 1.3.0
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0)
Classic VM (build 1.3.0, J2RE 1.3.0 IBM build cx130-20010502 (JIT enabled: jitc)
2002-04-24 04:58:09,658 ERROR [STDERR]
trust me on this... only impose VM pain on those that really want to use
IIOP.
marcf
|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Dain
|Sundstrom
|Sent: Tuesday, April 23, 2002 3:59 PM
|To: marc fleury
|Cc: [EMAIL PROTECTED]
|Subject: Re:
Number of tests run: 579
Successful tests: 533
Errors:30
Failures: 16
[time of test: 24 April 2002 0:37 GMT]
[java.version: 1.3.0]
[java.vendor: IBM Corporation]
Francisco the error that I am seeing
my VM is
java version 1.3.0
Java(TM) 2 Runtime Environment, Standard Edition
(build 1.3.0)
Classic VM (build 1.3.0, J2RE 1.3.0 IBM build
cx130-20010502 (JIT enabled: jitc)
This is a known problem in the IBM VM.
Just commited some changes
Bugs item #547831, was opened at 2002-04-23 16:17
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=547831group_id=22866
Category: JBossMQ
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Randy Dey-Toth (rdeytoth)
Assigned to:
Number of tests run: 572
Successful tests: 523
Errors:32
Failures: 17
[time of test: 24 April 2002 1:40 GMT]
[java.version: 1.3.0]
[java.vendor: IBM Corporation]
Could you please update your CVS tree and try again?
(The warning message and all spurious JacORB output
should also vanish.)
It works, thank you
marcf
* * *
View thread online: http://jboss.org/forums/thread.jsp?forum=66thread=13812
___
I can certainly do a clean CO and then build... But why wouldn't the CVS
update pick it up?
Hutner
From: lsanders [EMAIL PROTECTED]
Date: Tue, 23 Apr 2002 11:27:26 -0700
To: JBoss Dev [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] Branch_3_0 Not Running?
That line in MainDeployer refers to a
Hey, I have just started integrating SwiftMQ for use in my production
environment at work and by doing so I have notice d that we might have
some issues with the JMS RA.
Clayton Wheeler responsed to a message I wrote in the SwiftMQ forums
with a document he wrote about getting it to work:
Looking over the last bit of this doc about Xids and JBossTX...
JBossTX starts the global ID numbering from 1 each time it runs, so the global IDs
are not very unique. Needless to say, this could stand some improvement.
Why don't we use a org.jboss.util.id.UID or org.jboss.util.GUID here for
Number of tests run: 566
Successful tests: 542
Errors:17
Failures: 7
[time of test: 24 April 2002 3:28 GMT]
[java.version: 1.3.1]
[java.vendor: Blackdown Java-Linux
OK alarik just commited the fix to CVS,
please do me a favor, rm whatever you have for JBoss, cvs co jboss-all, build, run,
test, let me know.
thanks, hope it works for you
* * *
View thread online: http://jboss.org/forums/thread.jsp?forum=66thread=13794
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
JAVA VERSION DETAILS
java version 1.3.1
Java(TM) 2 Runtime Environment, Standard
OK
I commited the workaround for this bug.
DAVE, please do me a favor and test your deployment, please let me know if it works or
not.
more in a separate mail.
* * *
View thread online: http://jboss.org/forums/thread.jsp?forum=66thread=13431
___
Someone (I think it might have been David) mentioned something about diffing the HEAD
and 3.0 branches.
Does anyone know if there is a good way todo this?
I am a little concerned that some fixes are going into HEAD and are not making it into
the 3.0 branch. If there is a nice tool that
Can someone look into why this started happening again. And if it is a
problem on the server side can we fix it so that it accuratly reports
when the server does not shutdown.
Please.
--jason
[EMAIL PROTECTED] wrote:
=
Try something like this:
cvs -q diff -r Branch_3_0 -r HEAD | grep RCS
It's not the best, but it gets the job done.
-Larry
Someone (I think it might have been David) mentioned something about
diffing the HEAD and 3.0 branches.
Does anyone know if there is a good way todo this?
I am a
So I commited a workaround for the RFE that jung has with SUN.
Essentially it all amounts to making the ULR mono-threaded and relinqueshing the locks
as we go. It's pretty simple stuff since it is a subset of the locking in the
container. Plus it is the kind of stuff I get off with :)
Ok
PS: instructions
remove your current codebase
cvs co jboss-all
I think this is extreme, but certainly won't hurt
build/sh build.sh
If you choose not to re-checkout then:
build/build.sh clean most
=)
--jason
___
Jboss-development mailing
I've been using cvs -q diff -r Branch_3_0 -r HEAD
which works pretty well except that any changed file, the versions differ,
so you get a lot of spurious crap. I was about to ask you if there was
something we could do with cvs keyword expansion so only real differences
showed up.
david jencks
Number of tests run: 579
Successful tests: 555
Errors:15
Failures: 9
[time of test: 24 April 2002 5:13 GMT]
[java.version: 1.3.1]
[java.vendor: Blackdown Java-Linux
Also, in Ant 1.5 there is a new cvstagdiff / task that spits out a xml formatted
report.
http://cvs.apache.org/viewcvs/~checkout~/jakarta-ant/docs/manual/CoreTasks/cvstagdiff.html
Dave
* * *
View thread online: http://jboss.org/forums/thread.jsp?forum=66thread=13850
Title: Nachricht
Ilet it be
recatecorizedunder RFE. Now we are in the Top25! The shown ranking is
slightly behind the actual votes (414!). We should be 6th place
now.
http://developer.java.sun.com/developer/bugParade/top25rfes.html
You are a great
bunch of Java connaisseurs ;-) Go ahead,
Title: Message
I
wonder if issues classified as RFE's are less likely to be fixed/implemented
than issues classified as bugs. It seems like those RFE's at the top of that
list have been there a LONG time.
-Original Message-From:
[EMAIL PROTECTED]
[mailto:[EMAIL
Title: Message
problem is, sun doesn't think it's a bug in the first
place, so if it's classified as a bug it will never get
fixed
-Original Message-From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Matt
HumphreySent: Tuesday, April 23, 2002 1:29 PMTo: 'Jung ,
71 matches
Mail list logo
