CvsChangeLog also looks promising.
--jason
* * *
View thread online: http://jboss.org/forums/thread.jsp?forum=66&thread=13850
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Shit so does XmlProperty.. but still no app level xml include? Or is it that I just
can not find it?
--jason
* * *
View thread online: http://jboss.org/forums/thread.jsp?forum=66&thread=13850
___
Jboss-development mailing list
[EMAIL PROTECTED]
htt
I just tried deploying under /foo and got the same results.
=(
I have alos cross posted the main thread to jetty-discuss.
--jason
-
This mail sent through IMP: http://horde.org/imp/
___
Jboss-developm
Yes, that´s what the deadlock (hopefully) was about ... two threads loading
classes simultaneously ... I think that
Marc now has a promising (and ingenious, I didn´t think about the
synchronized - synchronized() relation the whole time!) workaround.
CGJ
-Ursprüngliche Nachricht-
Von: Ala
Hi Jason
According to my experience it is only applied on the root of your web
application like http://localhost:8080/test
if your web app is deployed to '/test' and the filter set to '/*'. But the
entire filter part of 2.3 in my opinion suffers from 1.0s disease it is
slightly underspecified and
=
==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 Edi
Number of tests run: 566
Successful tests: 540
Errors:17
Failures: 9
[time of test: 24 April 2002 7:27 GMT]
[java.version: 1.3.1]
[java.vendor: Sun Microsystems Inc.]
It would appear this also happens with directories under /, like
http://localhost:8080:/test where http://localhost:8080:/test/index.jsp works fine.
=(
--jason
* * *
View thread online: http://jboss.org/forums/thread.jsp?forum=66&thread=13857
___
J
Great! So we can build web pages with xslt to make this readable. Do you
know what the timeline is for the next Ant release?
--jason
Quoting Dave <[EMAIL PROTECTED]>:
> Also, in Ant 1.5 there is a new task that spits out a xml
> formatted report.
>
> http://cvs.apache.org/viewcvs/~checko
Hey, I am not sure if this is a real problem or if I just have my webapp
misconfigured... but it looks like there is a problem outside of my config.
I have been trying to setup a test environemnt for SiteMesh. SiteMesh uses servlet
filters to apply the decorator pattern to jsp pages... which i
Also, in Ant 1.5 there is a new 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=66&thread=13850
___
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 Te
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
>
>
>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 m
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 se
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
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:
>=
>=
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 wi
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=66&thread=13431
___
=
==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 Edi
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=66&thread=13794
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 Te
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
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:
htt
> 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=66&thread=13812
___
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]
[java
> 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
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]
[java
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: [JBoss-de
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]
Bugs item #547831, was opened at 2002-04-23 16:17
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=547831&group_id=22866
Category: JBossMQ
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Randy Dey-Toth (rdeytoth)
Assigned to
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 s
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
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
Can't we just require 1.3.1 or 1.4? I thought we were only going to
support JDKs back one version. Also, this is only a JBoss 3.0 thing;
people mostly starting to use this for development, so we can and should
force users to use a more resent JDK.
-dain
marc fleury wrote:
> righto... I sti
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
|---
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)
> the
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 t
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
>t
he...
did rm on the old stuff
then a CLEAN CO
then build (builds fine btw)
then start and I get an error from IIOP.
what gives?
something about jacob.properties not being found
Am I alone in seeing this?
I want to fix the CL stuff and will try right now
* * *
View thread online: http://jbos
Patches item #547792, was opened at 2002-04-23 14:26
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376687&aid=547792&group_id=22866
Category: JBossServer
Group: v2.4 (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Lucas McGregor (lmcgregor)
Assign
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
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 of
> 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/
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 sy
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 T
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
> t
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) Cl
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.
>
> D:\Devel
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 m
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: org.jboss.proxy.compiler.ProxyAssembl
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 MainDeploye
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]>
Sen
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 wr
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 org.jb
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 ,
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 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 lib/jb
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]
https:
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
|org.jboss.m
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)
Bugs item #547616, was opened at 2002-04-23 15:06
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=547616&group_id=22866
Category: None
Group: None
Status: Closed
Resolution: Rejected
Priority: 5
Submitted By: Ludovic Claude (ludovicc)
Assigned to: Nobody/
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
org/jboss/metadata/jboss_2_4.
Bugs item #547616, was opened at 2002-04-23 15:06
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=547616&group_id=22866
Category: None
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Ludovic Claude (ludovicc)
Assigned to: Nobod
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=detail&atid=376685&aid=547616&group_id=22866
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ludovic Claude (ludovicc)
Assigned to: Nobody/Anonym
|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 operat
Patches item #547586, was opened at 2002-04-23 09:16
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376687&aid=547586&group_id=22866
Category: None
Group: v2.4 BETA (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Roland King (rolandking)
Assigned t
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 connect
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
|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. Si
Title: Nachricht
I let it be
recatecorized under 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 ahea
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
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 Rep
Of course, it must prepend the JDK-shit, sorry did cut&paste 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
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
Feature Requests item #547494, was opened at 2002-04-23 03:43
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376688&aid=547494&group_id=22866
Category: JBossCMP
Group: v3.0 Rabbit Hole
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: No
Change Notes item #547479, was opened at 2002-04-23 12:34
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=381174&aid=547479&group_id=22866
Category: JBossMX
Group: None
Status: Open
Priority: 5
Submitted By: Juha Lindfors (juhalindfors)
Assigned to: Juha Lindfors (j
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 syn
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 UnifiedClassLoa
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 an
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.
> My reading of the spec is that it avoids all of these issues by only
> ever allowing one co
=
==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 Edi
Number of tests run: 566
Successful tests: 539
Errors:18
Failures: 9
[time of test: 23 April 2002 8:19 GMT]
[java.version: 1.3.1]
[java.vendor: Sun Microsystems Inc.]
85 matches
Mail list logo
