From orion at cora.nwra.com Mon Jul 3 17:00:32 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 03 Jul 2006 11:00:32 -0600 Subject: [fedora-java] gcjwebplugin-test package In-Reply-To: <1149850332.9469.7.camel@localhost.localdomain> References: <1149840475.2843.12.camel@localhost.localdomain> <1149850332.9469.7.camel@localhost.localdomain> Message-ID: <44A94D30.8090801@cora.nwra.com> Mark Wielaard wrote: > > Nice one! It just worked. Groovy Cool Jiving indeed. > For people wanting to try this out and see some working applets in > actions see http://developer.classpath.org/Applets and please add any > applets you find that don't work (yet!) to that page so we have a list > of issues to look at and make this thing even better. Mark, just tried this URL and got a not found error. Is there an updated location? -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From green at redhat.com Mon Jul 3 17:29:00 2006 From: green at redhat.com (Anthony Green) Date: Mon, 03 Jul 2006 10:29:00 -0700 Subject: [fedora-java] gcjwebplugin-test package In-Reply-To: <44A94D30.8090801@cora.nwra.com> References: <1149840475.2843.12.camel@localhost.localdomain> <1149850332.9469.7.camel@localhost.localdomain> <44A94D30.8090801@cora.nwra.com> Message-ID: <1151947740.2880.0.camel@localhost.localdomain> On Mon, 2006-07-03 at 11:00 -0600, Orion Poplawski wrote: > Mark Wielaard wrote: > > > > Nice one! It just worked. Groovy Cool Jiving indeed. > > For people wanting to try this out and see some working applets in > > actions see http://developer.classpath.org/Applets and please add any > > applets you find that don't work (yet!) to that page so we have a list > > of issues to look at and make this thing even better. > > Mark, just tried this URL and got a not found error. Is there an > updated location? > http://developer.classpath.org/mediation/Applets AG From mark at klomp.org Mon Jul 3 17:29:08 2006 From: mark at klomp.org (Mark Wielaard) Date: Mon, 03 Jul 2006 19:29:08 +0200 Subject: [fedora-java] gcjwebplugin-test package In-Reply-To: <44A94D30.8090801@cora.nwra.com> References: <1149840475.2843.12.camel@localhost.localdomain> <1149850332.9469.7.camel@localhost.localdomain> <44A94D30.8090801@cora.nwra.com> Message-ID: <1151947748.2526.0.camel@elsschot.wildebeest.org> On Mon, 2006-07-03 at 11:00 -0600, Orion Poplawski wrote: > Mark Wielaard wrote: > > > > Nice one! It just worked. Groovy Cool Jiving indeed. > > For people wanting to try this out and see some working applets in > > actions see http://developer.classpath.org/Applets and please add any > > applets you find that don't work (yet!) to that page so we have a list > > of issues to look at and make this thing even better. > > Mark, just tried this URL and got a not found error. Is there an > updated location? http://developer.classpath.org/mediation/Applets From orion at cora.nwra.com Mon Jul 3 19:57:30 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 03 Jul 2006 13:57:30 -0600 Subject: [fedora-java] gcjwebplugin-test package In-Reply-To: <1149840475.2843.12.camel@localhost.localdomain> References: <1149840475.2843.12.camel@localhost.localdomain> Message-ID: <44A976AA.5010309@cora.nwra.com> Anthony Green wrote: > I don't know what this will do if you have Sun's plugin installed as > well (I don't). Well, about:plugins lists them both, with the Sun plugin listed first, and it does appear to take precedence. This is with the JPackage java-1.5.0-sun-plugin rpm. Setting the java alternative to the gcjwebplugin-test package breaks the link in /usr/lib/mozilla/plugins and allows the gcjwebplugin to take precedence. -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From overholt at redhat.com Thu Jul 6 16:08:54 2006 From: overholt at redhat.com (Andrew Overholt) Date: Thu, 06 Jul 2006 12:08:54 -0400 Subject: [fedora-java] jedit install on fc3, fc4 or fc5 In-Reply-To: <77A76E40-C3DE-4AE9-8EDB-479B6A9B3EFE@bestweb.net> References: <77A76E40-C3DE-4AE9-8EDB-479B6A9B3EFE@bestweb.net> Message-ID: <1152202134.3343.5.camel@tophat.toronto.redhat.com> On Sat, 2006-24-06 at 16:01 -0400, ed anderson wrote: > Can Jedit be installed using jpackage on either os fc3, fc4 or fc5? This should probably be sent to the jpackage mailing list. Andrew From green at redhat.com Sun Jul 9 14:24:31 2006 From: green at redhat.com (Anthony Green) Date: Sun, 09 Jul 2006 07:24:31 -0700 Subject: [fedora-java] Patch for azureus timeout problem Message-ID: <1152455071.3123.145.camel@localhost.localdomain> Hi Tom, Could you please apply the attached patch to FC5's java-1.4.2-gcj-compat? It fixes a timeout problem in azureus. This fix is already in bouncycastle 1.33 which you've packaged for FC6. See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=187103 for a little more info. The java-1.4.2-gcj-compat spec file is a little funky. I just applied it with.. patch -p0 < %{PATCH0} ..in the %build section. Thanks, AG -------------- next part -------------- A non-text attachment was scrubbed... Name: java-gcj-compat-bcprov-X962NamedCurves.patch Type: text/x-patch Size: 625 bytes Desc: not available URL: From green at redhat.com Sun Jul 9 17:06:54 2006 From: green at redhat.com (Anthony Green) Date: Sun, 09 Jul 2006 10:06:54 -0700 Subject: [fedora-java] FC6 gcj notes Message-ID: <1152464814.3123.169.camel@localhost.localdomain> A few random FC6 gcj comments... I'm not sure if this has been mentioned on the list at all, but since FC6 will be shipping with GCC 4.1.x, a decision has been made to backport all the great GNU Classpath/libgcj work from GCC HEAD into the FC6 4.1.x branch. Among other things, this means we'll also get gcjwebplugin. The whitelist dialog box in gcjwebplugin is pretty intimidating. I was wondering if we could add a button to it that would pop up a Fedora wiki page in a browser explaining the situation a little better to newbies. I'd be willing to write the page if somebody could add the button. FE now contains all of the dependencies for the MIDI synthesizer providers I wrote (dssi, jack-audio-connection-kit, etc). I'm not willing to bet we can pull these into Core. Should I extract those providers from GNU Classpath and make an FE package out of them? Having Eclipse 3.2 in FC6 is awesome. I am able to remove a number of SWT patches from azureus and rssowl now that we have SWT 3.2. However... I can't optimize Azureus because of this: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19505 RSSOwl won't run because of this: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27271 Are there any other pet bugs that need to be fixed before FC6? Karsten hasn't been asking me about FOP for a long time. I wonder if that means the Fedora docs guys have moved on to a different PDF solution. I suspect that FOP will run with the FC6 gcj. Any reason to believe otherwise? AG From aph at redhat.com Mon Jul 10 09:52:13 2006 From: aph at redhat.com (Andrew Haley) Date: Mon, 10 Jul 2006 10:52:13 +0100 Subject: [fedora-java] FC6 gcj notes In-Reply-To: <1152464814.3123.169.camel@localhost.localdomain> References: <1152464814.3123.169.camel@localhost.localdomain> Message-ID: <17586.9037.68747.3416@zebedee.pink> Anthony Green writes: > The whitelist dialog box in gcjwebplugin is pretty intimidating. Good! The intention (surely?) is to make sure the chance of someone not understanding the situation is zero. > I was wondering if we could add a button to it that would pop up a > Fedora wiki page in a browser explaining the situation a little > better to newbies. I'd be willing to write the page if somebody > could add the button. > > > FE now contains all of the dependencies for the MIDI synthesizer > providers I wrote (dssi, jack-audio-connection-kit, etc). I'm not > willing to bet we can pull these into Core. Should I extract those > providers from GNU Classpath and make an FE package out of them? > > > Having Eclipse 3.2 in FC6 is awesome. I am able to remove a number of > SWT patches from azureus and rssowl now that we have SWT 3.2. > However... > I can't optimize Azureus because of this: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19505 Mmm. Jeff Law suggested a way to rewrite that patch which might be acceptable. I may be able to investigate this week. Andrew. From mark at klomp.org Tue Jul 11 13:38:29 2006 From: mark at klomp.org (Mark Wielaard) Date: Tue, 11 Jul 2006 15:38:29 +0200 Subject: [fedora-java] FC6 gcj notes In-Reply-To: <1152464814.3123.169.camel@localhost.localdomain> References: <1152464814.3123.169.camel@localhost.localdomain> Message-ID: <1152625110.2721.97.camel@elsschot.wildebeest.org> Hi, On Sun, 2006-07-09 at 10:06 -0700, Anthony Green wrote: > I'm not sure if this has been mentioned on the list at all, but since > FC6 will be shipping with GCC 4.1.x, a decision has been made to > backport all the great GNU Classpath/libgcj work from GCC HEAD into the > FC6 4.1.x branch. Among other things, this means we'll also get > gcjwebplugin. Great! This will be a huge boost in the number of applications that can be supported on the free stack in FC6 out of the box. But note that the GNU Classpath on GCC HEAD is some bastard "gui only" port of an old GNU Classpath CVS version from about a month ago. It has some really embarrassing bugs in it. We did a lot of testing and fixing of the graphics layer since then (and at least one really nasty bug was fixed only this weekend). So you really don't want to ship with what is in GCC HEAD now. At the minimum a new sync with Classpath CVS should be done for the graphics layers. We will try to make a new GNU Classpath snapshot soon (this weekend/next week, but no promises) that has gone through all the QA procedures. A lot of application smoke testing has been done in the last week, but at least a full comparision for regressions against the full Mauve testsuite should be done before we can be confident about creating a new release. Cheers, Mark From fitzsim at redhat.com Tue Jul 11 13:53:25 2006 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Tue, 11 Jul 2006 09:53:25 -0400 Subject: [fedora-java] FC6 gcj notes In-Reply-To: <1152625110.2721.97.camel@elsschot.wildebeest.org> References: <1152464814.3123.169.camel@localhost.localdomain> <1152625110.2721.97.camel@elsschot.wildebeest.org> Message-ID: <44B3AD55.6070702@redhat.com> Mark Wielaard wrote: > Hi, > > On Sun, 2006-07-09 at 10:06 -0700, Anthony Green wrote: >> I'm not sure if this has been mentioned on the list at all, but since >> FC6 will be shipping with GCC 4.1.x, a decision has been made to >> backport all the great GNU Classpath/libgcj work from GCC HEAD into the >> FC6 4.1.x branch. Among other things, this means we'll also get >> gcjwebplugin. > > Great! This will be a huge boost in the number of applications that can > be supported on the free stack in FC6 out of the box. > > But note that the GNU Classpath on GCC HEAD is some bastard "gui only" > port of an old GNU Classpath CVS version from about a month ago. It has > some really embarrassing bugs in it. We did a lot of testing and fixing > of the graphics layer since then (and at least one really nasty bug was > fixed only this weekend). So you really don't want to ship with what is > in GCC HEAD now. At the minimum a new sync with Classpath CVS should be > done for the graphics layers. We will try to make a new GNU Classpath > snapshot soon (this weekend/next week, but no promises) that has gone > through all the QA procedures. A lot of application smoke testing has > been done in the last week, but at least a full comparision for > regressions against the full Mauve testsuite should be done before we > can be confident about creating a new release. Yes, if the schedules work out I'd like to see the new GNU Classpath snapshot imported to GCJ mainline and the Red Hat 4.1 branch (Rawhide), between FC6test2 and FC6test3. That said, everything is stalled on the libgcj-bc.so work right now. If that isn't done in time we'll be stuck with GCJ 4.1 stock in FC6. Tom From green at redhat.com Tue Jul 11 14:04:28 2006 From: green at redhat.com (Anthony Green) Date: Tue, 11 Jul 2006 07:04:28 -0700 Subject: [fedora-java] FC6 gcj notes In-Reply-To: <44B3AD55.6070702@redhat.com> References: <1152464814.3123.169.camel@localhost.localdomain> <1152625110.2721.97.camel@elsschot.wildebeest.org> <44B3AD55.6070702@redhat.com> Message-ID: <1152626668.2751.23.camel@localhost.localdomain> On Tue, 2006-07-11 at 09:53 -0400, Thomas Fitzsimmons wrote: > That said, everything is stalled on the libgcj-bc.so work right > now. If that isn't done in time we'll be stuck with GCJ 4.1 stock in > FC6. Ouch. Is libgcj-bc.so is supposed to be library that -findirect-dispatch binaries link against? What is the advantage of introducing this? AG From fitzsim at redhat.com Tue Jul 11 14:11:51 2006 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Tue, 11 Jul 2006 10:11:51 -0400 Subject: [fedora-java] FC6 gcj notes In-Reply-To: <1152626668.2751.23.camel@localhost.localdomain> References: <1152464814.3123.169.camel@localhost.localdomain> <1152625110.2721.97.camel@elsschot.wildebeest.org> <44B3AD55.6070702@redhat.com> <1152626668.2751.23.camel@localhost.localdomain> Message-ID: <44B3B1A7.6040106@redhat.com> Anthony Green wrote: > On Tue, 2006-07-11 at 09:53 -0400, Thomas Fitzsimmons wrote: >> That said, everything is stalled on the libgcj-bc.so work right >> now. If that isn't done in time we'll be stuck with GCJ 4.1 stock in >> FC6. > > Ouch. Is libgcj-bc.so is supposed to be library that > -findirect-dispatch binaries link against? What is the advantage of > introducing this? libgcj-bc.so's SONAME (libgcj-bc.so.1) stays constant, meaning that BC libraries do not need to be relinked when libgcj.so's version changes. Tom From alcapcom at gmail.com Thu Jul 13 14:46:01 2006 From: alcapcom at gmail.com (alcapcom) Date: Thu, 13 Jul 2006 16:46:01 +0200 Subject: [fedora-java] Dependence bug in all optional task provided by ant.spec file. Message-ID: <4ccd9dcb0607130746j7df615a0l2c862fac88418ff7@mail.gmail.com> Hello, I found this bug by compiling a java application with mock. Simple example: yum install ant ant-apache-regexp The regexp task is not found by ant, to make it woking, ant-nodeps package must be installed manually. I put the question here before opening a new bug with a patch for the ant.spec file on bugzilla, in order to know if it is a known bug? Cheers From green at redhat.com Tue Jul 18 16:21:10 2006 From: green at redhat.com (Anthony Green) Date: Tue, 18 Jul 2006 09:21:10 -0700 Subject: [fedora-java] decoupling libgcj from gcc.src.rpm In-Reply-To: <1149841034.2843.19.camel@localhost.localdomain> References: <1149608744.2522.36.camel@localhost.localdomain> <1149841034.2843.19.camel@localhost.localdomain> Message-ID: <1153239670.2666.83.camel@localhost.localdomain> Jakub - I should have copied you on the original thread. We had been discussing decoupling the libgcj SRPM from the gcc SRPM so we can push java runtime fixes out more frequently than gcc updates. The idea would be for you to continue to build & test libgcj as part of the gcc package, but delete it after installation and don't package it. Then we'll just make a new SRPM based on the gcc sources that we can patch and push out on a more frequent basis. What do you think of this idea? AG On Fri, 2006-06-09 at 01:17 -0700, Anthony Green wrote: > Here's what a libgcj source RPM could look like (using FC5)... > > http://people.redhat.com/green/libgcj-4.1.1-1.fc5.src.rpm > > This source RPM builds, so feel free to try it. > > You'll see that the SOURCES directory contains a script called > libgcj-copy-source.sh. This script generates the libgcj source tarball > from portions of the prepped gcc sources. > > Using a libgcj source RPM like this means we can easily add our own > patches, rebuild and deploy on a schedule that is independent from the > gcc update schedule. > > I'm going to have sporadic email access for the next 10 days or so. I > just wanted to get this out for comment before I take off. > > Thanks, > > AG > > > -- > fedora-devel-java-list mailing list > fedora-devel-java-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-java-list From tromey at redhat.com Tue Jul 18 18:17:55 2006 From: tromey at redhat.com (Tom Tromey) Date: 18 Jul 2006 12:17:55 -0600 Subject: [fedora-java] decoupling libgcj from gcc.src.rpm In-Reply-To: <1153239670.2666.83.camel@localhost.localdomain> References: <1149608744.2522.36.camel@localhost.localdomain> <1149841034.2843.19.camel@localhost.localdomain> <1153239670.2666.83.camel@localhost.localdomain> Message-ID: >>>>> "Anthony" == Anthony Green writes: Anthony> We had been discussing decoupling the libgcj SRPM from the Anthony> gcc SRPM so we can push java runtime fixes out more Anthony> frequently than gcc updates. FWIW the primary motivation is so that we can push out libgcj bug fixes more rapidly. For instance, the zip fix for RSSOwl... and Anthony has mentioned some XML fix for OO.o, but I don't remember that one. Tom From tromey at redhat.com Tue Jul 18 18:24:11 2006 From: tromey at redhat.com (Tom Tromey) Date: 18 Jul 2006 12:24:11 -0600 Subject: [fedora-java] FC6 gcj notes In-Reply-To: <44B3AD55.6070702@redhat.com> References: <1152464814.3123.169.camel@localhost.localdomain> <1152625110.2721.97.camel@elsschot.wildebeest.org> <44B3AD55.6070702@redhat.com> Message-ID: >>>>> "Tom" == Thomas Fitzsimmons writes: Tom> Yes, if the schedules work out I'd like to see the new GNU Classpath Tom> snapshot imported to GCJ mainline and the Red Hat 4.1 branch Tom> (Rawhide), between FC6test2 and FC6test3. Piling on, I'd like us to ship the 'ecj' branch of gcj instead. This is a major upgrade including generics. It's not clear whether we can do this in a reasonable timeframe though. And I'm sure some would argue that we've already passed the point of reasonableness. Tom From green at redhat.com Tue Jul 18 18:41:16 2006 From: green at redhat.com (Anthony Green) Date: Tue, 18 Jul 2006 11:41:16 -0700 Subject: [fedora-java] decoupling libgcj from gcc.src.rpm In-Reply-To: References: <1149608744.2522.36.camel@localhost.localdomain> <1149841034.2843.19.camel@localhost.localdomain> <1153239670.2666.83.camel@localhost.localdomain> Message-ID: <1153248076.2666.127.camel@localhost.localdomain> On Tue, 2006-07-18 at 12:17 -0600, Tom Tromey wrote: > FWIW the primary motivation is so that we can push out libgcj bug > fixes more rapidly. For instance, the zip fix for RSSOwl... and > Anthony has mentioned some XML fix for OO.o, but I don't remember > that one. Actually, it wasn't an XML fix - it was a fix that impacted OO.o xslt output: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182263 There were other bugs as well, like the Eclipse-impacting deadlock problem. AG From david at zarb.org Tue Jul 18 18:48:18 2006 From: david at zarb.org (David Walluck) Date: Tue, 18 Jul 2006 14:48:18 -0400 Subject: [fedora-java] FC6 gcj notes In-Reply-To: References: <1152464814.3123.169.camel@localhost.localdomain> <1152625110.2721.97.camel@elsschot.wildebeest.org> <44B3AD55.6070702@redhat.com> Message-ID: <44BD2CF2.6060909@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom Tromey wrote: > Piling on, I'd like us to ship the 'ecj' branch of gcj instead. > This is a major upgrade including generics. Does the ecj branch have any runtime support for generics, or is it just compile-time support? > It's not clear whether we can do this in a reasonable timeframe though. > And I'm sure some would argue that we've already passed the point of > reasonableness. I don't think it matters that it's being done late in the test cycle. The new classpath versions are generally so much better than the old ones, that I think it will be worth it. I will be wanted to test the libgcj rpm whenever it is released. I was actually able to build HEAD (4.2) with the 4.1.1 compiler with a few changes, but then the bins don't look in the right place for the .spec file, etc. I don't know if that kind of setup is supported anyway, but at least HEAD already has 0.91 checked in. - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFEvSzyN5thZBYlTwkRAjz9AJ9JAvjlgDdrScH/SWCW7HU5Y7VKIgCeOm2m 3dGfq5M/XCLoTMDO5R0S/xI= =wBcS -----END PGP SIGNATURE----- From tromey at redhat.com Tue Jul 18 18:54:21 2006 From: tromey at redhat.com (Tom Tromey) Date: 18 Jul 2006 12:54:21 -0600 Subject: [fedora-java] FC6 gcj notes In-Reply-To: <44BD2CF2.6060909@zarb.org> References: <1152464814.3123.169.camel@localhost.localdomain> <1152625110.2721.97.camel@elsschot.wildebeest.org> <44B3AD55.6070702@redhat.com> <44BD2CF2.6060909@zarb.org> Message-ID: >>>>> "David" == David Walluck writes: David> Does the ecj branch have any runtime support for generics, or is it just David> compile-time support? Mostly just the compile-time support. It does support some of the new reflection data, but not annotations, which are the most important bit. (Actually much of this support has been written, at least on the runtime side. We're really just missing a piece from Classpath... if we managed to import 0.92 we could fix this up after the release.) David> I will be wanted to test the libgcj rpm whenever it is released. I was David> actually able to build HEAD (4.2) with the 4.1.1 compiler with a few David> changes, but then the bins don't look in the right place for the .spec David> file, etc. I don't know if that kind of setup is supported anyway, but David> at least HEAD already has 0.91 checked in. Bryce back-ported trunk libjava to the 4.1 compiler. I think this is in rawhide but I am not completely sure. Tom From mark at klomp.org Thu Jul 20 19:15:53 2006 From: mark at klomp.org (Mark Wielaard) Date: Thu, 20 Jul 2006 21:15:53 +0200 Subject: [fedora-java] FC6 gcj notes In-Reply-To: <44BD2CF2.6060909@zarb.org> References: <1152464814.3123.169.camel@localhost.localdomain> <1152625110.2721.97.camel@elsschot.wildebeest.org> <44B3AD55.6070702@redhat.com> <44BD2CF2.6060909@zarb.org> Message-ID: <1153422953.5640.3.camel@localhost.localdomain> Hi, On Tue, 2006-07-18 at 14:48 -0400, David Walluck wrote: > I don't think it matters that it's being done late in the test cycle. > The new classpath versions are generally so much better than the old > ones, that I think it will be worth it. Thanks! We are always working hard to make sure every release is only better and doesn't have bad regressions. > I will be wanted to test the libgcj rpm whenever it is released. I was > actually able to build HEAD (4.2) with the 4.1.1 compiler with a few > changes, but then the bins don't look in the right place for the .spec > file, etc. I don't know if that kind of setup is supported anyway, but > at least HEAD already has 0.91 checked in. And there is now a patch for 0.92-pre (hopefully close to 0.92 final) for HEAD: http://gcc.gnu.org/ml/java/2006-07/msg00057.html Testers welcome! Hopefully we will be able to backport most of that to 4.1 Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From david at zarb.org Thu Jul 20 22:32:26 2006 From: david at zarb.org (David Walluck) Date: Thu, 20 Jul 2006 18:32:26 -0400 Subject: [fedora-java] FC6 gcj notes In-Reply-To: <1153422953.5640.3.camel@localhost.localdomain> References: <1152464814.3123.169.camel@localhost.localdomain> <1152625110.2721.97.camel@elsschot.wildebeest.org> <44B3AD55.6070702@redhat.com> <44BD2CF2.6060909@zarb.org> <1153422953.5640.3.camel@localhost.localdomain> Message-ID: <44C0047A.70801@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mark Wielaard wrote: > And there is now a patch for 0.92-pre (hopefully close to 0.92 final) > for HEAD: http://gcc.gnu.org/ml/java/2006-07/msg00057.html > Testers welcome! Hopefully we will be able to backport most of that to > 4.1 Why is gcjwebplugin being installed to $HOME? This makes no sense as part of an rpm build. Unfortunately, it just locks my firefox solid on x86-64, so I would not want it enabled by default in an rpm anyway. (I did get a message at one point and if I see it again, I will try to post a bug). It seems to be waiting indefinitely for something and in the meantime the browser just hangs. Note also that we should now have gjarsigner and gkeytool in addition to gappletviewer, so java-1.4.2-gcj-compat should be set up to make slave symlinks for these three new bins. - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFEwAR6N5thZBYlTwkRAmuFAJ9AY8KZV/1jcx18izLTBo07xV/WogCeJ2s6 9g8YDday+9hmvlYe+CoOtGk= =fu6m -----END PGP SIGNATURE----- From fitzsim at redhat.com Thu Jul 20 23:19:10 2006 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Thu, 20 Jul 2006 19:19:10 -0400 Subject: [fedora-java] FC6 gcj notes In-Reply-To: <44C0047A.70801@zarb.org> References: <1152464814.3123.169.camel@localhost.localdomain> <1152625110.2721.97.camel@elsschot.wildebeest.org> <44B3AD55.6070702@redhat.com> <44BD2CF2.6060909@zarb.org> <1153422953.5640.3.camel@localhost.localdomain> <44C0047A.70801@zarb.org> Message-ID: <44C00F6E.3080501@redhat.com> Hi, David Walluck wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Mark Wielaard wrote: >> And there is now a patch for 0.92-pre (hopefully close to 0.92 final) >> for HEAD: http://gcc.gnu.org/ml/java/2006-07/msg00057.html >> Testers welcome! Hopefully we will be able to backport most of that to >> 4.1 > > Why is gcjwebplugin being installed to $HOME? This makes no sense as > part of an rpm build. What RPM are you building, exactly? > Unfortunately, it just locks my firefox solid on > x86-64, so I would not want it enabled by default in an rpm anyway. (I > did get a message at one point and if I see it again, I will try to post > a bug). It seems to be waiting indefinitely for something and in the > meantime the browser just hangs. Try running gappletviewer standalone, e.g.: gappletviewer http://thisiscool.com When the browser hangs like this, it means that gappletviewer is misconfigured. If gappletviewer is not misconfigured then the browser will never hang. > > Note also that we should now have gjarsigner and gkeytool in addition to > gappletviewer, so java-1.4.2-gcj-compat should be set up to make slave > symlinks for these three new bins. See: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=127537 The libgcj backport, which adds libgcjwebplugin.so and gappletviewer to the libgcj RPM for the first time, is building right now; as soon as it lands in Rawhide I will release a new version of java-1.4.2-gcj-compat that includes java-1.4.2-gcj-compat-plugin. Tom From david at zarb.org Fri Jul 21 00:13:24 2006 From: david at zarb.org (David Walluck) Date: Thu, 20 Jul 2006 20:13:24 -0400 Subject: [fedora-java] FC6 gcj notes In-Reply-To: <44C00F6E.3080501@redhat.com> References: <1152464814.3123.169.camel@localhost.localdomain> <1152625110.2721.97.camel@elsschot.wildebeest.org> <44B3AD55.6070702@redhat.com> <44BD2CF2.6060909@zarb.org> <1153422953.5640.3.camel@localhost.localdomain> <44C0047A.70801@zarb.org> <44C00F6E.3080501@redhat.com> Message-ID: <44C01C24.7040105@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thomas Fitzsimmons wrote: > What RPM are you building, exactly? Sorry, I didn't mean to imply that there was an rpm. I meant that as a warning for when the new libgcj rpm appears. > Try running gappletviewer standalone, e.g.: > > gappletviewer http://thisiscool.com > > When the browser hangs like this, it means that gappletviewer is > misconfigured. If gappletviewer is not misconfigured then the browser > will never hang. Running standalone, I get Exception in thread "main" java.lang.NoClassDefFoundError: gnu.classpath.tools.appletviewer.Main tools.zip is supposedly added to the classpath using - -Xbootclasspath/p:"${tools_cp}" But gij doesn't support this, at least on the 4.1.1 release I am using (jamvm works). > See: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=127537 > > The libgcj backport, which adds libgcjwebplugin.so and gappletviewer to > the libgcj RPM for the first time, is building right now; as soon as it > lands in Rawhide I will release a new version of java-1.4.2-gcj-compat > that includes java-1.4.2-gcj-compat-plugin. So, how is the plugin installation handled? It seems that the GNU plugin will override, say, the blackdown plugin for any applets. since the GNU plugin isn't going through the alternatives system and is just getting put in the plugin path first. In addition to not liking the configure for the plugin install location, I don't like how it is looking for mozilla, when it seems you should also be able to use mozilla-firefox without problems. - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFEwBwkN5thZBYlTwkRAu2rAJ99njMI8qM0A8rXtl7dMj6I//ny5QCfUZxE IzR8vAa7AmNetwrDhIJiZu4= =zClp -----END PGP SIGNATURE----- From fitzsim at redhat.com Fri Jul 21 02:36:27 2006 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Thu, 20 Jul 2006 22:36:27 -0400 Subject: [fedora-java] FC6 gcj notes In-Reply-To: <44C01C24.7040105@zarb.org> References: <1152464814.3123.169.camel@localhost.localdomain> <1152625110.2721.97.camel@elsschot.wildebeest.org> <44B3AD55.6070702@redhat.com> <44BD2CF2.6060909@zarb.org> <1153422953.5640.3.camel@localhost.localdomain> <44C0047A.70801@zarb.org> <44C00F6E.3080501@redhat.com> <44C01C24.7040105@zarb.org> Message-ID: <44C03DAB.4090507@redhat.com> Hi, David Walluck wrote: > So, how is the plugin installation handled? It seems that the GNU plugin > will override, say, the blackdown plugin for any applets. since the GNU > plugin isn't going through the alternatives system and is just getting > put in the plugin path first. In addition to not liking the configure > for the plugin install location, I don't like how it is looking for > mozilla, when it seems you should also be able to use mozilla-firefox > without problems. I'm not sure where these assertions are coming from. What are you trying to build/do, exactly? First, GNU Classpath no longer installs the plugin in ~/.mozilla/plugins by default. Instead, there is an "install-plugin" target in $builddir/native/plugin that copies libgcjwebplugin.so to ~/.mozilla/plugins, if the GNU Classpath developer runs the target manually. This "install-plugin" target is not run by default. Second, in Red Hat distributions we do use alternatives to manage Java plugins. In the RHEL packages, I introduced the alternatives-managed /usr/lib/mozilla/plugins/libjavaplugin.so symlink. I'll do the same for Fedora. (A long time ago, I proposed this approach to plugin packaging to the JPackage maintainers, and provided a patch to java-1.4.2-ibm to implement it, but it never made it into the official JPackage packages. I've been discussing it with Daniel though and he thinks it's a good idea, so I'm going to try again to have it accepted). Finally, while GNU Classpath does require the Mozilla headers and libraries to build the plugin, so does every Mozilla plugin. And java-1.4.2-gcj-compat-plugin will only require the /usr/lib/mozilla/plugins directory, meaning that the plugin will be recognized by any browser that supports Netscape plugins. If you want, add yourself to the CC for this bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=127537 and review java-1.4.2-gcj-compat-plugin after I've committed it. Tom From david at zarb.org Fri Jul 21 03:07:38 2006 From: david at zarb.org (David Walluck) Date: Thu, 20 Jul 2006 23:07:38 -0400 Subject: [fedora-java] FC6 gcj notes In-Reply-To: <44C03DAB.4090507@redhat.com> References: <1152464814.3123.169.camel@localhost.localdomain> <1152625110.2721.97.camel@elsschot.wildebeest.org> <44B3AD55.6070702@redhat.com> <44BD2CF2.6060909@zarb.org> <1153422953.5640.3.camel@localhost.localdomain> <44C0047A.70801@zarb.org> <44C00F6E.3080501@redhat.com> <44C01C24.7040105@zarb.org> <44C03DAB.4090507@redhat.com> Message-ID: <44C044FA.9010402@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thomas Fitzsimmons wrote: > I'm not sure where these assertions are coming from. What are you > trying to build/do, exactly? > > First, GNU Classpath no longer installs the plugin in ~/.mozilla/plugins > by default. Instead, there is an "install-plugin" target in > $builddir/native/plugin that copies libgcjwebplugin.so to > ~/.mozilla/plugins, if the GNU Classpath developer runs the target > manually. This "install-plugin" target is not run by default. Sorry, again. This isn't a criticism of some rpm in fedora because I don't know that one exists. Rather, I was talking about the upstream configure and install process for the plugin. So maybe this is not the best forum, but if $(libdir)/mozilla/plugins is a more sane location, I don't see why it doesn't choose that instead of $HOME/.mozilla/plugins. The comment about firefox is how the plugin is fining the development headers to build against. I think you are right on how it should work after it is built, though. - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFEwET6N5thZBYlTwkRAp09AKCNnVWE0euvnRnavG8VDBXNHKXchQCfUcwJ +xQDkzTb6K6wk2NIReCfzFY= =QNoW -----END PGP SIGNATURE----- From green at redhat.com Sun Jul 23 20:41:27 2006 From: green at redhat.com (Anthony Green) Date: Sun, 23 Jul 2006 13:41:27 -0700 Subject: [fedora-java] where is libjawt.so? Message-ID: <1153687287.2765.2.camel@localhost.localdomain> Tom, Jakub, I'm trying to rebuild jogl against the latest devel bits and I don't see where libjawt.so moved to. I only see libgcjawt.so. Pointers? Thanks! AG From overholt at redhat.com Sun Jul 23 21:35:01 2006 From: overholt at redhat.com (Andrew Overholt) Date: Sun, 23 Jul 2006 17:35:01 -0400 Subject: [fedora-java] where is libjawt.so? In-Reply-To: <1153687287.2765.2.camel@localhost.localdomain> References: <1153687287.2765.2.camel@localhost.localdomain> Message-ID: <20060723213500.GA22009@redhat.com> * Anthony Green [2006-07-23 16:41]: > > I'm trying to rebuild jogl against the latest devel bits and I don't > see where libjawt.so moved to. I only see libgcjawt.so. Pointers? It's no longer libgcjawt but libjawt. -L%{_jvmdir}/java/jre/lib/%{_arch} I think it's now consistent with all of the proprietary VMs. HTH, Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From green at redhat.com Mon Jul 24 17:18:22 2006 From: green at redhat.com (Anthony Green) Date: Mon, 24 Jul 2006 10:18:22 -0700 Subject: [fedora-java] where is libjawt.so? In-Reply-To: <1153687287.2765.2.camel@localhost.localdomain> References: <1153687287.2765.2.camel@localhost.localdomain> Message-ID: <1153761502.7268.41.camel@localhost.localdomain> On Sun, 2006-07-23 at 13:41 -0700, Anthony Green wrote: > Tom, Jakub, > > I'm trying to rebuild jogl against the latest devel bits and I don't > see where libjawt.so moved to. I only see libgcjawt.so. Pointers? fitzim answered this on #fedora-java. I just thought I'd post here for the lurkers. rawhide is busted & everything will be refreshed/fixed tomorrow. AG From overholt at redhat.com Mon Jul 24 18:25:21 2006 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 24 Jul 2006 14:25:21 -0400 Subject: [fedora-java] CDT hover error Message-ID: <20060724182521.GA9672@redhat.com> Hi Jeff, With the latest autotools work you've done (in eclipse-cdt in rawhide), I can't seem to get hover help working. I get this in /.metadata/.log: !ENTRY org.eclipse.cdt.ui 4 2 2006-07-24 14:18:24.831 !MESSAGE Problems occurred when invoking code from plug-in: "org.eclipse.cdt.ui". !STACK 0 java.lang.NullPointerException at org.eclipse.core.internal.runtime.Activator.getURLConverter(org.eclipse.equinox.common_3.2.0.v20060603.jar.so) at org.eclipse.core.runtime.FileLocator.toFileURL(org.eclipse.equinox.common_3.2.0.v20060603.jar.so) at org.eclipse.core.runtime.Platform.asLocalURL(org.eclipse.core.runtime_3.2.0.v20060603.jar.so) at com.redhat.eclipse.cdt.autotools.ui.LibHover.buildDocPath(com.redhat.eclipse.cdt.autotools_0.0.2.jar.so) at com.redhat.eclipse.cdt.autotools.ui.LibHover.initialize(com.redhat.eclipse.cdt.autotools_0.0.2.jar.so) at org.eclipse.cdt.internal.ui.text.CHelpProviderDescriptor$1.run(CHelpProviderDescriptor.java:106) at org.eclipse.core.runtime.SafeRunner.run(org.eclipse.equinox.common_3.2.0.v20060603.jar.so) at org.eclipse.core.runtime.Platform.run(org.eclipse.core.runtime_3.2.0.v20060603.jar.so) at org.eclipse.cdt.internal.ui.text.CHelpProviderDescriptor.getCHelpProvider(CHelpProviderDescriptor.java:111) at org.eclipse.cdt.internal.ui.text.CHelpProviderDescriptor.getCHelpProvider(CHelpProviderDescriptor.java:126) at org.eclipse.cdt.internal.ui.text.CHelpProviderDescriptor.getCHelpBookDescriptors(CHelpProviderDescriptor.java:132) at org.eclipse.cdt.internal.ui.text.CHelpProviderDescriptor.getCHelpBookDescriptors(CHelpProviderDescriptor.java:152) at org.eclipse.cdt.internal.ui.text.CHelpProviderDescriptor.getEnabledMatchedCHelpBooks(CHelpProviderDescriptor.java:156) at org.eclipse.cdt.internal.ui.text.CHelpSettings.getFunctionInfo(CHelpSettings.java:117) at org.eclipse.cdt.internal.ui.CHelpProviderManager.getFunctionInfo(org.eclipse.cdt.ui_3.1.0.200607240538.jar.so) at org.eclipse.cdt.internal.ui.text.c.hover.CDocHover.getHoverInfo(CDocHover.java:71) at org.eclipse.cdt.internal.ui.text.c.hover.BestMatchHover.getHoverInfo(BestMatchHover.java:100) at org.eclipse.cdt.internal.ui.text.c.hover.CEditorTextHoverProxy.getHoverInfo(CEditorTextHoverProxy.java:64) at org.eclipse.jface.text.TextViewerHoverManager$4.run(org.eclipse.jface.text_3.2.0.v20060605-1400.jar.so) Any idea what's going on here? Thanks, Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: From aph at redhat.com Tue Jul 25 17:13:56 2006 From: aph at redhat.com (Andrew Haley) Date: Tue, 25 Jul 2006 18:13:56 +0100 Subject: [fedora-java] Regression in libgcj: spurious IncompatibleClassChangeError with BC-compiled code. Message-ID: <17606.20820.595037.919021@zebedee.pink> This happens if a class and its superclass are loaded by the boot classloader. If one if them is in the precompiled database and one isn't, we fail this check: if ( sub->loader != super->loader || !_Jv_ClassNameSamePackage (sub->name, super->name)) { throw_incompatible_class_change_error (sub->getName ()); } We fail this check becasue of this line in natVMClassLoader.cc // Record the defining loader. For the bootstrap class loader, // we record NULL. if (loader != bootLoader) klass->loader = loader; So, at the point of this test: sub->loader != super->loader sub->loader == bootLoader, and super->loader == NULL. All this happens because when a class is loaded by natSharedLibLoader, we do this: void _Jv_sharedlib_register_hook (jclass cls) { cls->protectionDomain = curHelper->domain; cls->loader = curLoader; if (! cls->engine) cls->engine = &_Jv_soleCompiledEngine; curHelper->registerClass(cls->getName(), cls); } note that we always set the loader; we don't check for it being the bootLoader. There are several ways to fix this. We need it for FC6. Andrew. 2006-07-25 Andrew Haley * gnu/gcj/runtime/natSharedLibLoader.cc (init): Don't set curLoader to VMClassLoader::bootLoader. --- natSharedLibLoader.cc~ 2006-07-25 16:47:05.000000000 +0100 +++ natSharedLibLoader.cc 2006-07-25 18:11:25.000000000 +0100 @@ -20,6 +20,8 @@ #include #include +#include + // If we're using the Boehm GC, then we need this include to override dlopen. #ifdef HAVE_BOEHM_GC // Set GC_DEBUG before including gc.h! @@ -87,7 +89,8 @@ flags = RTLD_GLOBAL | RTLD_LAZY; JvSynchronize dummy1(&java::lang::Class::class$); SharedLibDummy dummy2; - curLoader = loader; + curLoader = ((void*)loader == java::lang::VMClassLoader::bootLoader + ? NULL : loader); curHelper = this; _Jv_RegisterClassHook = _Jv_sharedlib_register_hook; _Jv_RegisterCoreHook = core_hook; From aph at redhat.com Tue Jul 25 18:17:04 2006 From: aph at redhat.com (Andrew Haley) Date: Tue, 25 Jul 2006 19:17:04 +0100 Subject: [fedora-java] Regression in libgcj: spurious IncompatibleClassChangeError with BC-compiled code. In-Reply-To: <1153851165.21427.9.camel@topcat.toronto.redhat.com> References: <17606.20820.595037.919021@zebedee.pink> <1153851165.21427.9.camel@topcat.toronto.redhat.com> Message-ID: <17606.24608.762046.658835@zebedee.pink> Vivek Lakshmanan writes: > hmmm fedora-devel-java-list was not included in my "reply-to-all". > Reposting here: > > On Tue, 2006-07-25 at 18:13 +0100, Andrew Haley wrote: > > This happens if a class and its superclass are loaded by the boot > > classloader. If one if them is in the precompiled database and one > > isn't, we fail this check: > > > > if ( sub->loader != super->loader > > || !_Jv_ClassNameSamePackage (sub->name, super->name)) > > { > > throw_incompatible_class_change_error (sub->getName ()); > > } > > > This is probably a manifestation of this bug. We just installed the > latest tomcat5, installed tomcat5-admin-webapps and tomcat5-webapps. > Trying to access either of these from the main tomcat5 startup page > causes an error. Attaching the catalina log. > > Let me know if you need help reproducing the bug. ... > Caused by: java.lang.IncompatibleClassChangeError: org.apache.xerces.impl.xpath.regex.Token$ModifierToken It's the same bug. Andrew. From fitzsim at redhat.com Tue Jul 25 19:34:18 2006 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Tue, 25 Jul 2006 15:34:18 -0400 Subject: [fedora-java] gcjwebplugin has landed in Rawhide Message-ID: <44C6723A.4090508@redhat.com> Hi, gcc-4.1.1-12, which contains libgcjwebplugin.so, went into Rawhide last night along with java-1.4.2-gcj-compat-plugin which installs an alternatives-managed "libjavaplugin.so" symlink in /usr/lib/mozilla/plugins. I closed the long-standing "Inclusion of gcjwebplugin" bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=127537 and updated the release notes with a "Handling Java Applets" section: http://fedoraproject.org/wiki/Docs/Beats/Java Rawhide users can install gcjwebplugin with "yum install java-1.4.2-gcj-compat-plugin". Please try this out, file bugs and comment on the release note additions. The GNU Classpath AWT and Swing code was in a state of flux when the backport that included gcjwebplugin was done (because of a large Java2D rewrite to make the Cairo backend the default), so there are some regressions in AWT and Swing applications for FC6test2. My post-test2 plan for gcjwebplugin is to gage the reaction of Rawhide users, and also to do another GUI backport from GNU Classpath HEAD to Fedora's libgcj, to fix the AWT and Swing regressions. If the reaction turns out to be overly negative, even after the new AWT and Swing backport, we can always make gcjwebplugin not installed by default, for FC6test3. For FC6test2 though, it is installed by default if the Internet group is selected. Tom From tromey at redhat.com Tue Jul 25 22:02:35 2006 From: tromey at redhat.com (Tom Tromey) Date: Tue, 25 Jul 2006 18:02:35 -0400 Subject: [fedora-java] gcjwebplugin has landed in Rawhide In-Reply-To: <44C6723A.4090508@redhat.com> References: <44C6723A.4090508@redhat.com> Message-ID: <17606.38139.838011.799482@localhost.localdomain> >>>>> "Tom" == Thomas Fitzsimmons writes: Tom> gcc-4.1.1-12, which contains libgcjwebplugin.so, went into Tom> Rawhide last night along with java-1.4.2-gcj-compat-plugin which Tom> installs an alternatives-managed "libjavaplugin.so" symlink in Tom> /usr/lib/mozilla/plugins. Congratulations! I know that a bunch of folks worked very hard to make this happen. Tom> My post-test2 plan for gcjwebplugin is to gage the reaction of Tom> Rawhide users, FWIW -- I've been using Anthony's earlier jamvm-based plugin on my laptop. I use it almost daily (always with the same applet :-), it has been quite nice. Tom> and also to do another GUI backport from GNU Classpath HEAD to Tom> Fedora's libgcj, to fix the AWT and Swing regressions. I wanted to follow up the earlier conversation about FC6 gcj -- the ecj work really was not ready on time, we missed it. It was all we could do to get this big backport in place. That is pretty disappointing... but FC7 will have an enormous upgrade. Tom From overholt at redhat.com Wed Jul 26 01:18:02 2006 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 25 Jul 2006 21:18:02 -0400 Subject: [fedora-java] [poohba@blkpoohba.dyndns.org: Getting java errors when trying to install limewire] Message-ID: <20060726011801.GA22575@redhat.com> See below from fedora-list. We don't expect limewire to work with what I'm assuming is FC5, right? Has anyone tried it with rawhide? Andrew ----- Forwarded message from Poohba ----- > From: Poohba > To: For users of Fedora Core releases > X-Mailer: Evolution 2.6.0 (2.6.0-1) > Date: Tue, 25 Jul 2006 20:10:20 -0400 > Subject: Getting java errors when trying to install limewire > > Is this because I don't have the correct or all of the java's needed? > > ./LimeWireLinux.bin > Preparing to install... > Extracting the installation resources from the installer archive... > Configuring the installer for this system's environment... > > Launching installer... > > Exception in thread "main" java.lang.NoClassDefFoundError: > com.zerog.lax.LAX > at gnu.java.lang.MainThread.run (libgcj.so.7) > Caused by: java.lang.ClassNotFoundException: com.zerog.lax.LAX not found > in > gnu.gcj.runtime.SystemClassLoader{urls=[file:/tmp/install.dir.14630/InstallerData/,file:/tmp/install.dir.14630/InstallerData/installer.zip], parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}} > at java.net.URLClassLoader.findClass (libgcj.so.7) > at java.lang.ClassLoader.loadClass (libgcj.so.7) > at java.lang.ClassLoader.loadClass (libgcj.so.7) > at java.lang.Class.forName (libgcj.so.7) > at gnu.java.lang.MainThread.run (libgcj.so.7) > > > yum install java* > Loading "installonlyn" plugin > Setting up Install Process > Setting up repositories > core > [1/3] > extras > [2/3] > updates > [3/3] > Reading repository metadata in from local files > Parsing package install arguments > Resolving Dependencies > --> Populating transaction set with selected packages. Please wait. > ---> Downloading header for javacc-demo to pack into transaction set. > javacc-demo-3.2-1jpp_6fc. 100% |=========================| 20 kB > 01:33 > ---> Package javacc-demo.i386 0:3.2-1jpp_6fc set to be updated > ---> Downloading header for java-clearsilver to pack into transaction > set. > ftp://mirror.newnanutilities.org/pub/fedora/linux/extras/5/i386/java-clearsilver-0.10.3-3.fc5.i386.rpm: [Errno 4] IOError: [Errno ftp error] (111, 'Connection refused') > Trying other mirror. > java-clearsilver-0.10.3-3 100% |=========================| 3.8 kB > 00:00 > ---> Package java-clearsilver.i386 0:0.10.3-3.fc5 set to be updated > ---> Downloading header for javacc to pack into transaction set. > ftp://ftp.tecnoera.com/pub/fedora/linux/core/5/i386/os/Fedora/RPMS/javacc-3.2-1jpp_6fc.i386.rpm: [Errno 4] IOError: [Errno ftp error] timed out > Trying other mirror. > javacc-3.2-1jpp_6fc.i386. 100% |=========================| 4.9 kB > 00:00 > ---> Package javacc.i386 0:3.2-1jpp_6fc set to be updated > ---> Downloading header for java-1.4.2-gcj-compat-javadoc to pack into > transaction set. > java-1.4.2-gcj-compat-jav 100% |=========================| 887 kB > 00:01 > ---> Package java-1.4.2-gcj-compat-javadoc.i386 0:1.4.2.0-40jpp_83rh set > to be updated > ---> Downloading header for javacc-manual to pack into transaction set. > javacc-manual-3.2-1jpp_6f 100% |=========================| 5.6 kB > 00:00 > ---> Package javacc-manual.i386 0:3.2-1jpp_6fc set to be updated > --> Running transaction check > > Dependencies Resolved > > ============================================================================= > Package Arch Version Repository > Size > ============================================================================= > Installing: > java-1.4.2-gcj-compat-javadoc i386 1.4.2.0-40jpp_83rh core 21 > M > java-clearsilver i386 0.10.3-3.fc5 extras > 85 k > javacc i386 3.2-1jpp_6fc core > 915 k > javacc-demo i386 3.2-1jpp_6fc core > 95 k > javacc-manual i386 3.2-1jpp_6fc core > 76 k > > Transaction Summary > ============================================================================= > Install 5 Package(s) > Update 0 Package(s) > Remove 0 Package(s) > Total download size: 22 M > Is this ok [y/N]: y > Downloading Packages: > (1/5): javacc-demo-3.2-1j 100% |=========================| 95 kB > 00:00 > (2/5): java-clearsilver-0 100% |=========================| 85 kB > 00:00 > (3/5): javacc-3.2-1jpp_6f 100% |=========================| 915 kB > 00:03 > (4/5): java-1.4.2-gcj-com 100% |=========================| 21 MB > 00:18 > (5/5): javacc-manual-3.2- 100% |=========================| 76 kB > 00:00 > warning: rpmts_HdrFromFdno: Header V3 DSA signature: NOKEY, key ID > 1ac70ce6 > Public key for java-clearsilver-0.10.3-3.fc5.i386.rpm is not installed > Retrieving GPG key from > file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-extras > Importing GPG key 0x1AC70CE6 "Fedora Project > " > Is this ok [y/N]: y > Key imported successfully > Running Transaction Test > Finished Transaction Test > Transaction Test Succeeded > Running Transaction > Installing: javacc-manual ######################### > [1/5] > Installing: javacc-demo ######################### > [2/5] > Installing: java-clearsilver ######################### > [3/5] > Installing: javacc ######################### > [4/5] > Installing: java-1.4.2-gcj-compat-javado ######################### > [5/5] > > Installed: java-1.4.2-gcj-compat-javadoc.i386 0:1.4.2.0-40jpp_83rh > java-clearsilver.i386 0:0.10.3-3.fc5 javacc.i386 0:3.2-1jpp_6fc > javacc-demo.i386 0:3.2-1jpp_6fc javacc-manual.i386 0:3.2-1jpp_6fc > Complete! > > > > -- > fedora-list mailing list > fedora-list at redhat.com > To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list ----- End forwarded message ----- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From vivekl at redhat.com Tue Jul 25 18:12:45 2006 From: vivekl at redhat.com (Vivek Lakshmanan) Date: Tue, 25 Jul 2006 14:12:45 -0400 Subject: [fedora-java] Regression in libgcj: spurious IncompatibleClassChangeError with BC-compiled code. In-Reply-To: <17606.20820.595037.919021@zebedee.pink> References: <17606.20820.595037.919021@zebedee.pink> Message-ID: <1153851165.21427.9.camel@topcat.toronto.redhat.com> hmmm fedora-devel-java-list was not included in my "reply-to-all". Reposting here: On Tue, 2006-07-25 at 18:13 +0100, Andrew Haley wrote: > This happens if a class and its superclass are loaded by the boot > classloader. If one if them is in the precompiled database and one > isn't, we fail this check: > > if ( sub->loader != super->loader > || !_Jv_ClassNameSamePackage (sub->name, super->name)) > { > throw_incompatible_class_change_error (sub->getName ()); > } > This is probably a manifestation of this bug. We just installed the latest tomcat5, installed tomcat5-admin-webapps and tomcat5-webapps. Trying to access either of these from the main tomcat5 startup page causes an error. Attaching the catalina log. Let me know if you need help reproducing the bug. Thanks, Vivek -------------- next part -------------- Created MBeanServer with ID: eq2guqag:-sridxr:0:to-fcjpp1.toronto.redhat.com:1 25-Jul-06 12:11:22 PM org.apache.catalina.core.AprLifecycleListener lifecycleEvent INFO: The Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /usr/lib/gcj-4.1.1 25-Jul-06 12:11:22 PM org.apache.coyote.http11.Http11BaseProtocol init INFO: Initializing Coyote HTTP/1.1 on http-8080 25-Jul-06 12:11:22 PM org.apache.catalina.startup.Catalina load INFO: Initialization processed in 2926 ms 25-Jul-06 12:11:22 PM org.apache.catalina.core.StandardService start INFO: Starting service Catalina 25-Jul-06 12:11:22 PM org.apache.catalina.core.StandardEngine start INFO: Starting Servlet Engine: Apache Tomcat/5.5.17 25-Jul-06 12:11:22 PM org.apache.catalina.core.StandardHost start INFO: XML validation disabled 25-Jul-06 12:11:22 PM org.apache.coyote.http11.Http11BaseProtocol start INFO: Starting Coyote HTTP/1.1 on http-8080 25-Jul-06 12:11:22 PM org.apache.jk.common.ChannelSocket init INFO: JK: ajp13 listening on /0.0.0.0:8009 25-Jul-06 12:11:22 PM org.apache.jk.server.JkMain start INFO: Jk running ID=0 time=0/81 config=null 25-Jul-06 12:11:22 PM org.apache.catalina.storeconfig.StoreLoader load INFO: Find registry server-registry.xml at classpath resource 25-Jul-06 12:11:22 PM org.apache.catalina.startup.Catalina start INFO: Server startup in 557 ms 25-Jul-06 12:15:44 PM org.apache.coyote.http11.Http11BaseProtocol pause INFO: Pausing Coyote HTTP/1.1 on http-8080 25-Jul-06 12:15:45 PM org.apache.catalina.core.StandardService stop INFO: Stopping service Catalina 25-Jul-06 12:15:45 PM org.apache.coyote.http11.Http11BaseProtocol destroy INFO: Stopping Coyote HTTP/1.1 on http-8080 25-Jul-06 12:15:45 PM org.apache.catalina.core.AprLifecycleListener lifecycleEvent INFO: Failed shutdown of Apache Portable Runtime Created MBeanServer with ID: eq2h0jzd:-shvmio:0:to-fcjpp1.toronto.redhat.com:1 25-Jul-06 12:15:50 PM org.apache.catalina.core.AprLifecycleListener lifecycleEvent INFO: The Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /usr/lib/gcj-4.1.1 25-Jul-06 12:15:50 PM org.apache.coyote.http11.Http11BaseProtocol init INFO: Initializing Coyote HTTP/1.1 on http-8080 25-Jul-06 12:15:50 PM org.apache.catalina.startup.Catalina load INFO: Initialization processed in 871 ms 25-Jul-06 12:15:51 PM org.apache.catalina.core.StandardService start INFO: Starting service Catalina 25-Jul-06 12:15:51 PM org.apache.catalina.core.StandardEngine start INFO: Starting Servlet Engine: Apache Tomcat/5.5.17 25-Jul-06 12:15:51 PM org.apache.catalina.core.StandardHost start INFO: XML validation disabled 25-Jul-06 12:15:51 PM org.apache.coyote.http11.Http11BaseProtocol start INFO: Starting Coyote HTTP/1.1 on http-8080 25-Jul-06 12:15:51 PM org.apache.jk.common.ChannelSocket init INFO: JK: ajp13 listening on /0.0.0.0:8009 25-Jul-06 12:15:51 PM org.apache.jk.server.JkMain start INFO: Jk running ID=0 time=0/82 config=null 25-Jul-06 12:15:51 PM org.apache.catalina.storeconfig.StoreLoader load INFO: Find registry server-registry.xml at classpath resource 25-Jul-06 12:15:51 PM org.apache.catalina.startup.Catalina start INFO: Server startup in 548 ms 25-Jul-06 12:15:53 PM org.apache.coyote.http11.Http11BaseProtocol pause INFO: Pausing Coyote HTTP/1.1 on http-8080 25-Jul-06 12:15:54 PM org.apache.catalina.core.StandardService stop INFO: Stopping service Catalina 25-Jul-06 12:15:54 PM org.apache.coyote.http11.Http11BaseProtocol destroy INFO: Stopping Coyote HTTP/1.1 on http-8080 25-Jul-06 12:15:54 PM org.apache.catalina.core.AprLifecycleListener lifecycleEvent INFO: Failed shutdown of Apache Portable Runtime Created MBeanServer with ID: eq2h0y76:-sbz4j9:0:to-fcjpp1.toronto.redhat.com:1 25-Jul-06 12:16:09 PM org.apache.catalina.core.AprLifecycleListener lifecycleEvent INFO: The Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /usr/lib/gcj-4.1.1 25-Jul-06 12:16:09 PM org.apache.coyote.http11.Http11BaseProtocol init INFO: Initializing Coyote HTTP/1.1 on http-8080 25-Jul-06 12:16:09 PM org.apache.catalina.startup.Catalina load INFO: Initialization processed in 876 ms 25-Jul-06 12:16:09 PM org.apache.catalina.core.StandardService start INFO: Starting service Catalina 25-Jul-06 12:16:09 PM org.apache.catalina.core.StandardEngine start INFO: Starting Servlet Engine: Apache Tomcat/5.5.17 25-Jul-06 12:16:09 PM org.apache.catalina.core.StandardHost start INFO: XML validation disabled 25-Jul-06 12:16:09 PM org.apache.coyote.http11.Http11BaseProtocol start INFO: Starting Coyote HTTP/1.1 on http-8080 25-Jul-06 12:16:09 PM org.apache.jk.common.ChannelSocket init INFO: JK: ajp13 listening on /0.0.0.0:8009 25-Jul-06 12:16:09 PM org.apache.jk.server.JkMain start INFO: Jk running ID=0 time=0/41 config=null 25-Jul-06 12:16:09 PM org.apache.catalina.storeconfig.StoreLoader load INFO: Find registry server-registry.xml at classpath resource 25-Jul-06 12:16:09 PM org.apache.catalina.startup.Catalina start INFO: Server startup in 521 ms 25-Jul-06 12:17:20 PM org.apache.coyote.http11.Http11BaseProtocol pause INFO: Pausing Coyote HTTP/1.1 on http-8080 25-Jul-06 12:17:21 PM org.apache.catalina.core.StandardService stop INFO: Stopping service Catalina 25-Jul-06 12:17:21 PM org.apache.coyote.http11.Http11BaseProtocol destroy INFO: Stopping Coyote HTTP/1.1 on http-8080 25-Jul-06 12:17:21 PM org.apache.catalina.core.AprLifecycleListener lifecycleEvent INFO: Failed shutdown of Apache Portable Runtime Created MBeanServer with ID: eq2h2l12:-sk4b49:0:to-fcjpp1.toronto.redhat.com:1 25-Jul-06 12:17:25 PM org.apache.catalina.core.AprLifecycleListener lifecycleEvent INFO: The Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /usr/lib/gcj-4.1.1 25-Jul-06 12:17:25 PM org.apache.coyote.http11.Http11BaseProtocol init INFO: Initializing Coyote HTTP/1.1 on http-8080 25-Jul-06 12:17:25 PM org.apache.catalina.startup.Catalina load INFO: Initialization processed in 869 ms 25-Jul-06 12:17:25 PM org.apache.catalina.core.StandardService start INFO: Starting service Catalina 25-Jul-06 12:17:25 PM org.apache.catalina.core.StandardEngine start INFO: Starting Servlet Engine: Apache Tomcat/5.5.17 25-Jul-06 12:17:25 PM org.apache.catalina.core.StandardHost start INFO: XML validation disabled 25-Jul-06 12:17:25 PM org.apache.coyote.http11.Http11BaseProtocol start INFO: Starting Coyote HTTP/1.1 on http-8080 25-Jul-06 12:17:25 PM org.apache.jk.common.ChannelSocket init INFO: JK: ajp13 listening on /0.0.0.0:8009 25-Jul-06 12:17:25 PM org.apache.jk.server.JkMain start INFO: Jk running ID=0 time=0/81 config=null 25-Jul-06 12:17:25 PM org.apache.catalina.storeconfig.StoreLoader load INFO: Find registry server-registry.xml at classpath resource 25-Jul-06 12:17:26 PM org.apache.catalina.startup.Catalina start INFO: Server startup in 550 ms 25-Jul-06 12:19:28 PM org.apache.catalina.core.ApplicationContext log INFO: ContextListener: contextInitialized() 25-Jul-06 12:19:28 PM org.apache.catalina.core.ApplicationContext log INFO: SessionListener: contextInitialized() 25-Jul-06 12:19:29 PM org.apache.catalina.core.ApplicationContext log INFO: ContextListener: contextInitialized() 25-Jul-06 12:19:29 PM org.apache.catalina.core.ApplicationContext log INFO: SessionListener: contextInitialized() 25-Jul-06 12:21:32 PM org.apache.catalina.core.ApplicationContext log INFO: org.apache.webapp.balancer.BalancerFilter: init(): ruleChain: [org.apache.webapp.balancer.RuleChain: [org.apache.webapp.balancer.rules.URLStringMatchRule: Target string: News / Redirect URL: http://www.cnn.com], [org.apache.webapp.balancer.rules.RequestParameterRule: Target param name: paramName / Target param value: paramValue / Redirect URL: http://www.yahoo.com], [org.apache.webapp.balancer.rules.AcceptEverythingRule: Redirect URL: http://jakarta.apache.org]] 25-Jul-06 12:21:42 PM org.apache.coyote.http11.Http11BaseProtocol pause INFO: Pausing Coyote HTTP/1.1 on http-8080 25-Jul-06 12:21:43 PM org.apache.catalina.core.StandardService stop INFO: Stopping service Catalina 25-Jul-06 12:21:43 PM org.apache.catalina.core.ApplicationContext log INFO: SessionListener: contextDestroyed() 25-Jul-06 12:21:43 PM org.apache.catalina.core.ApplicationContext log INFO: ContextListener: contextDestroyed() 25-Jul-06 12:21:43 PM org.apache.catalina.core.ApplicationContext log INFO: SessionListener: contextDestroyed() 25-Jul-06 12:21:43 PM org.apache.catalina.core.ApplicationContext log INFO: ContextListener: contextDestroyed() 25-Jul-06 12:21:44 PM org.apache.coyote.http11.Http11BaseProtocol destroy INFO: Stopping Coyote HTTP/1.1 on http-8080 25-Jul-06 12:21:44 PM org.apache.catalina.core.AprLifecycleListener lifecycleEvent INFO: Failed shutdown of Apache Portable Runtime Created MBeanServer with ID: eq2h88sp:-rtxqeo:0:to-fcjpp1.toronto.redhat.com:1 25-Jul-06 12:21:49 PM org.apache.catalina.core.AprLifecycleListener lifecycleEvent INFO: The Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /usr/lib/gcj-4.1.1 25-Jul-06 12:21:49 PM org.apache.coyote.http11.Http11BaseProtocol init INFO: Initializing Coyote HTTP/1.1 on http-8080 25-Jul-06 12:21:49 PM org.apache.catalina.startup.Catalina load INFO: Initialization processed in 880 ms 25-Jul-06 12:21:49 PM org.apache.catalina.core.StandardService start INFO: Starting service Catalina 25-Jul-06 12:21:49 PM org.apache.catalina.core.StandardEngine start INFO: Starting Servlet Engine: Apache Tomcat/5.5.17 25-Jul-06 12:21:49 PM org.apache.catalina.core.StandardHost start INFO: XML validation disabled 25-Jul-06 12:21:51 PM org.apache.catalina.core.ApplicationContext log INFO: ContextListener: contextInitialized() 25-Jul-06 12:21:51 PM org.apache.catalina.core.ApplicationContext log INFO: SessionListener: contextInitialized() 25-Jul-06 12:21:52 PM org.apache.catalina.core.ApplicationContext log INFO: ContextListener: contextInitialized() 25-Jul-06 12:21:52 PM org.apache.catalina.core.ApplicationContext log INFO: SessionListener: contextInitialized() 25-Jul-06 12:21:52 PM org.apache.catalina.core.ApplicationContext log INFO: org.apache.webapp.balancer.BalancerFilter: init(): ruleChain: [org.apache.webapp.balancer.RuleChain: [org.apache.webapp.balancer.rules.URLStringMatchRule: Target string: News / Redirect URL: http://www.cnn.com], [org.apache.webapp.balancer.rules.RequestParameterRule: Target param name: paramName / Target param value: paramValue / Redirect URL: http://www.yahoo.com], [org.apache.webapp.balancer.rules.AcceptEverythingRule: Redirect URL: http://jakarta.apache.org]] 25-Jul-06 12:21:52 PM org.apache.coyote.http11.Http11BaseProtocol start INFO: Starting Coyote HTTP/1.1 on http-8080 25-Jul-06 12:21:52 PM org.apache.jk.common.ChannelSocket init INFO: JK: ajp13 listening on /0.0.0.0:8009 25-Jul-06 12:21:52 PM org.apache.jk.server.JkMain start INFO: Jk running ID=0 time=0/165 config=null 25-Jul-06 12:21:53 PM org.apache.catalina.storeconfig.StoreLoader load INFO: Find registry server-registry.xml at classpath resource 25-Jul-06 12:21:53 PM org.apache.catalina.startup.Catalina start INFO: Server startup in 3751 ms 25-Jul-06 12:22:07 PM org.apache.struts.action.ActionServlet init SEVERE: Unable to initialize Struts ActionServlet due to an unexpected exception or error thrown, so marking the servlet as unavailable. Most likely, this is due to an incorrect or missing library dependency. java.lang.NoClassDefFoundError: org.apache.xerces.impl.xpath.regex.RegularExpression at java.lang.Class.initializeClass(libgcj.so.7rh) at org.apache.xerces.impl.dv.xs.XSSimpleTypeDecl.applyFacets(xerces-j2-2.7.1.jar.so) at org.apache.xerces.impl.dv.xs.XSSimpleTypeDecl.applyFacets1(xerces-j2-2.7.1.jar.so) at org.apache.xerces.impl.dv.xs.SchemaDVFactoryImpl.createBuiltInTypes(xerces-j2-2.7.1.jar.so) at org.apache.xerces.impl.dv.xs.SchemaDVFactoryImpl.(xerces-j2-2.7.1.jar.so) at java.lang.Class.initializeClass(libgcj.so.7rh) at java.lang.Class.newInstance(libgcj.so.7rh) at org.apache.xerces.impl.dv.ObjectFactory.newInstance(xerces-j2-2.7.1.jar.so) at org.apache.xerces.impl.dv.SchemaDVFactory.getInstance(xerces-j2-2.7.1.jar.so) at org.apache.xerces.impl.dv.SchemaDVFactory.getInstance(xerces-j2-2.7.1.jar.so) at org.apache.xerces.impl.xs.SchemaGrammar$BuiltinSchemaGrammar.(Unknown Source) at org.apache.xerces.impl.xs.SchemaGrammar.(Unknown Source) at java.lang.Class.initializeClass(libgcj.so.7rh) at org.apache.xerces.impl.xs.XMLSchemaValidator.(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.configurePipeline(Unknown Source) at org.apache.xerces.parsers.XIncludeAwareParserConfiguration.configurePipeline(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) at org.apache.commons.digester.Digester.parse(jakarta-commons-digester-1.7.jar.so) at org.apache.struts.action.ActionServlet.parseModuleConfigFile(struts-1.2.8.jar.so) at org.apache.struts.action.ActionServlet.initModuleConfig(struts-1.2.8.jar.so) at org.apache.struts.action.ActionServlet.init(struts-1.2.8.jar.so) at org.apache.webapp.admin.ApplicationServlet.init(ApplicationServlet.java:105) at javax.servlet.GenericServlet.init(tomcat5-servlet-2.4-api-5.5.17.jar.so) at org.apache.catalina.core.StandardWrapper.loadServlet(catalina-5.5.17.jar.soei6hxg.so) at org.apache.catalina.core.StandardWrapper.allocate(catalina-5.5.17.jar.soei6hxg.so) at org.apache.catalina.core.ApplicationDispatcher.invoke(catalina-5.5.17.jar.soei6hxg.so) at org.apache.catalina.core.ApplicationDispatcher.doInclude(catalina-5.5.17.jar.soei6hxg.so) at org.apache.catalina.core.ApplicationDispatcher.include(catalina-5.5.17.jar.soei6hxg.so) at admin.login_jsp._jspService(catalina-admin-5.5.17.jar.so) at org.apache.jasper.runtime.HttpJspBase.service(jasper5-runtime-5.5.17.jar.so) at javax.servlet.http.HttpServlet.service(tomcat5-servlet-2.4-api-5.5.17.jar.so) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(catalina-5.5.17.jar.soei6hxg.so) at org.apache.catalina.core.ApplicationFilterChain.doFilter(catalina-5.5.17.jar.soei6hxg.so) at org.apache.catalina.core.ApplicationDispatcher.invoke(catalina-5.5.17.jar.soei6hxg.so) at org.apache.catalina.core.ApplicationDispatcher.processRequest(catalina-5.5.17.jar.soei6hxg.so) at org.apache.catalina.core.ApplicationDispatcher.doForward(catalina-5.5.17.jar.soei6hxg.so) at org.apache.catalina.core.ApplicationDispatcher.forward(catalina-5.5.17.jar.soei6hxg.so) at org.apache.catalina.authenticator.FormAuthenticator.forwardToLoginPage(catalina-5.5.17.jar.soei6hxg.so) at org.apache.catalina.authenticator.FormAuthenticator.authenticate(catalina-5.5.17.jar.soei6hxg.so) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(catalina-5.5.17.jar.soei6hxg.so) at org.apache.catalina.core.StandardHostValve.invoke(catalina-5.5.17.jar.soei6hxg.so) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(catalina-5.5.17.jar.soei6hxg.so) at org.apache.catalina.connector.CoyoteAdapter.service(catalina-5.5.17.jar.soei6hxg.so) at org.apache.coyote.http11.Http11Processor.process(tomcat-http-5.5.17.jar.so) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(tomcat-http-5.5.17.jar.so) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(tomcat-util-5.5.17.jar.so) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(tomcat-util-5.5.17.jar.so) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(tomcat-util-5.5.17.jar.so) at java.lang.Thread.run(libgcj.so.7rh) Caused by: java.lang.IncompatibleClassChangeError: org.apache.xerces.impl.xpath.regex.Token$ModifierToken at java.lang.VMClassLoader.defineClass(libgcj.so.7rh) at java.lang.ClassLoader.defineClass(libgcj.so.7rh) at java.security.SecureClassLoader.defineClass(libgcj.so.7rh) at java.net.URLClassLoader.findClass(libgcj.so.7rh) at gnu.gcj.runtime.BootClassLoader.bootLoadClass(libgcj.so.7rh) at java.lang.VMClassLoader.loadClass(libgcj.so.7rh) at java.lang.ClassLoader.loadClass(libgcj.so.7rh) at java.lang.ClassLoader.loadClass(libgcj.so.7rh) at java.lang.Class.initializeClass(libgcj.so.7rh) ...53 more 25-Jul-06 12:22:08 PM org.apache.catalina.core.ApplicationContext log INFO: Marking servlet action as unavailable 25-Jul-06 12:22:08 PM org.apache.catalina.core.ApplicationDispatcher invoke SEVERE: Allocate exception for servlet action javax.servlet.UnavailableException: org.apache.xerces.impl.xpath.regex.RegularExpression at org.apache.struts.action.ActionServlet.init(struts-1.2.8.jar.so) at org.apache.webapp.admin.ApplicationServlet.init(ApplicationServlet.java:105) at javax.servlet.GenericServlet.init(tomcat5-servlet-2.4-api-5.5.17.jar.so) at org.apache.catalina.core.StandardWrapper.loadServlet(catalina-5.5.17.jar.soei6hxg.so) at org.apache.catalina.core.StandardWrapper.allocate(catalina-5.5.17.jar.soei6hxg.so) at org.apache.catalina.core.ApplicationDispatcher.invoke(catalina-5.5.17.jar.soei6hxg.so) at org.apache.catalina.core.ApplicationDispatcher.doInclude(catalina-5.5.17.jar.soei6hxg.so) at org.apache.catalina.core.ApplicationDispatcher.include(catalina-5.5.17.jar.soei6hxg.so) at admin.login_jsp._jspService(catalina-admin-5.5.17.jar.so) at org.apache.jasper.runtime.HttpJspBase.service(jasper5-runtime-5.5.17.jar.so) at javax.servlet.http.HttpServlet.service(tomcat5-servlet-2.4-api-5.5.17.jar.so) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(catalina-5.5.17.jar.soei6hxg.so) at org.apache.catalina.core.ApplicationFilterChain.doFilter(catalina-5.5.17.jar.soei6hxg.so) at org.apache.catalina.core.ApplicationDispatcher.invoke(catalina-5.5.17.jar.soei6hxg.so) at org.apache.catalina.core.ApplicationDispatcher.processRequest(catalina-5.5.17.jar.soei6hxg.so) at org.apache.catalina.core.ApplicationDispatcher.doForward(catalina-5.5.17.jar.soei6hxg.so) at org.apache.catalina.core.ApplicationDispatcher.forward(catalina-5.5.17.jar.soei6hxg.so) at org.apache.catalina.authenticator.FormAuthenticator.forwardToLoginPage(catalina-5.5.17.jar.soei6hxg.so) at org.apache.catalina.authenticator.FormAuthenticator.authenticate(catalina-5.5.17.jar.soei6hxg.so) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(catalina-5.5.17.jar.soei6hxg.so) at org.apache.catalina.core.StandardHostValve.invoke(catalina-5.5.17.jar.soei6hxg.so) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(catalina-5.5.17.jar.soei6hxg.so) at org.apache.catalina.connector.CoyoteAdapter.service(catalina-5.5.17.jar.soei6hxg.so) at org.apache.coyote.http11.Http11Processor.process(tomcat-http-5.5.17.jar.so) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(tomcat-http-5.5.17.jar.so) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(tomcat-util-5.5.17.jar.so) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(tomcat-util-5.5.17.jar.so) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(tomcat-util-5.5.17.jar.so) at java.lang.Thread.run(libgcj.so.7rh) 25-Jul-06 12:22:08 PM org.apache.catalina.core.ApplicationDispatcher invoke SEVERE: Servlet.service() for servlet admin.login_jsp threw exception javax.servlet.UnavailableException: org.apache.xerces.impl.xpath.regex.RegularExpression at org.apache.struts.action.ActionServlet.init(struts-1.2.8.jar.so) at org.apache.webapp.admin.ApplicationServlet.init(ApplicationServlet.java:105) at javax.servlet.GenericServlet.init(tomcat5-servlet-2.4-api-5.5.17.jar.so) at org.apache.catalina.core.StandardWrapper.loadServlet(catalina-5.5.17.jar.soei6hxg.so) at org.apache.catalina.core.StandardWrapper.allocate(catalina-5.5.17.jar.soei6hxg.so) at org.apache.catalina.core.ApplicationDispatcher.invoke(catalina-5.5.17.jar.soei6hxg.so) at org.apache.catalina.core.ApplicationDispatcher.doInclude(catalina-5.5.17.jar.soei6hxg.so) at org.apache.catalina.core.ApplicationDispatcher.include(catalina-5.5.17.jar.soei6hxg.so) at admin.login_jsp._jspService(catalina-admin-5.5.17.jar.so) at org.apache.jasper.runtime.HttpJspBase.service(jasper5-runtime-5.5.17.jar.so) at javax.servlet.http.HttpServlet.service(tomcat5-servlet-2.4-api-5.5.17.jar.so) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(catalina-5.5.17.jar.soei6hxg.so) at org.apache.catalina.core.ApplicationFilterChain.doFilter(catalina-5.5.17.jar.soei6hxg.so) at org.apache.catalina.core.ApplicationDispatcher.invoke(catalina-5.5.17.jar.soei6hxg.so) at org.apache.catalina.core.ApplicationDispatcher.processRequest(catalina-5.5.17.jar.soei6hxg.so) at org.apache.catalina.core.ApplicationDispatcher.doForward(catalina-5.5.17.jar.soei6hxg.so) at org.apache.catalina.core.ApplicationDispatcher.forward(catalina-5.5.17.jar.soei6hxg.so) at org.apache.catalina.authenticator.FormAuthenticator.forwardToLoginPage(catalina-5.5.17.jar.soei6hxg.so) at org.apache.catalina.authenticator.FormAuthenticator.authenticate(catalina-5.5.17.jar.soei6hxg.so) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(catalina-5.5.17.jar.soei6hxg.so) at org.apache.catalina.core.StandardHostValve.invoke(catalina-5.5.17.jar.soei6hxg.so) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(catalina-5.5.17.jar.soei6hxg.so) at org.apache.catalina.connector.CoyoteAdapter.service(catalina-5.5.17.jar.soei6hxg.so) at org.apache.coyote.http11.Http11Processor.process(tomcat-http-5.5.17.jar.so) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(tomcat-http-5.5.17.jar.so) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(tomcat-util-5.5.17.jar.so) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(tomcat-util-5.5.17.jar.so) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(tomcat-util-5.5.17.jar.so) at java.lang.Thread.run(libgcj.so.7rh) 25-Jul-06 12:22:08 PM org.apache.catalina.core.ApplicationContext log INFO: Marking servlet admin.login_jsp as unavailable 25-Jul-06 12:22:08 PM org.apache.catalina.authenticator.FormAuthenticator forwardToLoginPage WARNING: Unexpected error forwarding to login page javax.servlet.UnavailableException: org.apache.xerces.impl.xpath.regex.RegularExpression at org.apache.struts.action.ActionServlet.init(struts-1.2.8.jar.so) at org.apache.webapp.admin.ApplicationServlet.init(ApplicationServlet.java:105) at javax.servlet.GenericServlet.init(tomcat5-servlet-2.4-api-5.5.17.jar.so) at org.apache.catalina.core.StandardWrapper.loadServlet(catalina-5.5.17.jar.soei6hxg.so) at org.apache.catalina.core.StandardWrapper.allocate(catalina-5.5.17.jar.soei6hxg.so) at org.apache.catalina.core.ApplicationDispatcher.invoke(catalina-5.5.17.jar.soei6hxg.so) at org.apache.catalina.core.ApplicationDispatcher.doInclude(catalina-5.5.17.jar.soei6hxg.so) at org.apache.catalina.core.ApplicationDispatcher.include(catalina-5.5.17.jar.soei6hxg.so) at admin.login_jsp._jspService(catalina-admin-5.5.17.jar.so) at org.apache.jasper.runtime.HttpJspBase.service(jasper5-runtime-5.5.17.jar.so) at javax.servlet.http.HttpServlet.service(tomcat5-servlet-2.4-api-5.5.17.jar.so) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(catalina-5.5.17.jar.soei6hxg.so) at org.apache.catalina.core.ApplicationFilterChain.doFilter(catalina-5.5.17.jar.soei6hxg.so) at org.apache.catalina.core.ApplicationDispatcher.invoke(catalina-5.5.17.jar.soei6hxg.so) at org.apache.catalina.core.ApplicationDispatcher.processRequest(catalina-5.5.17.jar.soei6hxg.so) at org.apache.catalina.core.ApplicationDispatcher.doForward(catalina-5.5.17.jar.soei6hxg.so) at org.apache.catalina.core.ApplicationDispatcher.forward(catalina-5.5.17.jar.soei6hxg.so) at org.apache.catalina.authenticator.FormAuthenticator.forwardToLoginPage(catalina-5.5.17.jar.soei6hxg.so) at org.apache.catalina.authenticator.FormAuthenticator.authenticate(catalina-5.5.17.jar.soei6hxg.so) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(catalina-5.5.17.jar.soei6hxg.so) at org.apache.catalina.core.StandardHostValve.invoke(catalina-5.5.17.jar.soei6hxg.so) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(catalina-5.5.17.jar.soei6hxg.so) at org.apache.catalina.connector.CoyoteAdapter.service(catalina-5.5.17.jar.soei6hxg.so) at org.apache.coyote.http11.Http11Processor.process(tomcat-http-5.5.17.jar.so) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(tomcat-http-5.5.17.jar.so) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(tomcat-util-5.5.17.jar.so) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(tomcat-util-5.5.17.jar.so) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(tomcat-util-5.5.17.jar.so) at java.lang.Thread.run(libgcj.so.7rh) 25-Jul-06 12:23:16 PM org.apache.coyote.http11.Http11BaseProtocol pause INFO: Pausing Coyote HTTP/1.1 on http-8080 25-Jul-06 12:23:17 PM org.apache.catalina.core.StandardService stop INFO: Stopping service Catalina 25-Jul-06 12:23:17 PM org.apache.catalina.core.ApplicationContext log INFO: SessionListener: contextDestroyed() 25-Jul-06 12:23:17 PM org.apache.catalina.core.ApplicationContext log INFO: ContextListener: contextDestroyed() 25-Jul-06 12:23:17 PM org.apache.catalina.core.ApplicationContext log INFO: SessionListener: contextDestroyed() 25-Jul-06 12:23:17 PM org.apache.catalina.core.ApplicationContext log INFO: ContextListener: contextDestroyed() 25-Jul-06 12:23:17 PM org.apache.coyote.http11.Http11BaseProtocol destroy INFO: Stopping Coyote HTTP/1.1 on http-8080 25-Jul-06 12:23:17 PM org.apache.catalina.core.AprLifecycleListener lifecycleEvent INFO: Failed shutdown of Apache Portable Runtime Created MBeanServer with ID: eq2ha8x9:-slpruk:0:to-fcjpp1.toronto.redhat.com:1 25-Jul-06 12:23:22 PM org.apache.catalina.core.AprLifecycleListener lifecycleEvent INFO: The Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /usr/lib/gcj-4.1.1 25-Jul-06 12:23:23 PM org.apache.coyote.http11.Http11BaseProtocol init INFO: Initializing Coyote HTTP/1.1 on http-8080 25-Jul-06 12:23:23 PM org.apache.catalina.startup.Catalina load INFO: Initialization processed in 868 ms 25-Jul-06 12:23:23 PM org.apache.catalina.core.StandardService start INFO: Starting service Catalina 25-Jul-06 12:23:23 PM org.apache.catalina.core.StandardEngine start INFO: Starting Servlet Engine: Apache Tomcat/5.5.17 25-Jul-06 12:23:23 PM org.apache.catalina.core.StandardHost start INFO: XML validation disabled 25-Jul-06 12:23:25 PM org.apache.catalina.core.ApplicationContext log INFO: ContextListener: contextInitialized() 25-Jul-06 12:23:25 PM org.apache.catalina.core.ApplicationContext log INFO: SessionListener: contextInitialized() 25-Jul-06 12:23:25 PM org.apache.catalina.core.ApplicationContext log INFO: ContextListener: contextInitialized() 25-Jul-06 12:23:25 PM org.apache.catalina.core.ApplicationContext log INFO: SessionListener: contextInitialized() 25-Jul-06 12:23:25 PM org.apache.catalina.core.ApplicationContext log INFO: org.apache.webapp.balancer.BalancerFilter: init(): ruleChain: [org.apache.webapp.balancer.RuleChain: [org.apache.webapp.balancer.rules.URLStringMatchRule: Target string: News / Redirect URL: http://www.cnn.com], [org.apache.webapp.balancer.rules.RequestParameterRule: Target param name: paramName / Target param value: paramValue / Redirect URL: http://www.yahoo.com], [org.apache.webapp.balancer.rules.AcceptEverythingRule: Redirect URL: http://jakarta.apache.org]] 25-Jul-06 12:23:25 PM org.apache.coyote.http11.Http11BaseProtocol start INFO: Starting Coyote HTTP/1.1 on http-8080 25-Jul-06 12:23:26 PM org.apache.jk.common.ChannelSocket init INFO: JK: ajp13 listening on /0.0.0.0:8009 25-Jul-06 12:23:26 PM org.apache.jk.server.JkMain start INFO: Jk running ID=0 time=0/44 config=null 25-Jul-06 12:23:26 PM org.apache.catalina.storeconfig.StoreLoader load INFO: Find registry server-registry.xml at classpath resource 25-Jul-06 12:23:26 PM org.apache.catalina.startup.Catalina start INFO: Server startup in 3355 ms 25-Jul-06 12:23:34 PM org.apache.struts.action.ActionServlet init SEVERE: Unable to initialize Struts ActionServlet due to an unexpected exception or error thrown, so marking the servlet as unavailable. Most likely, this is due to an incorrect or missing library dependency. java.lang.NoClassDefFoundError: org.apache.xerces.impl.xpath.regex.RegularExpression at java.lang.Class.initializeClass(libgcj.so.7rh) at org.apache.xerces.impl.dv.xs.XSSimpleTypeDecl.applyFacets(xerces-j2-2.7.1.jar.so) at org.apache.xerces.impl.dv.xs.XSSimpleTypeDecl.applyFacets1(xerces-j2-2.7.1.jar.so) at org.apache.xerces.impl.dv.xs.SchemaDVFactoryImpl.createBuiltInTypes(xerces-j2-2.7.1.jar.so) at org.apache.xerces.impl.dv.xs.SchemaDVFactoryImpl.(xerces-j2-2.7.1.jar.so) at java.lang.Class.initializeClass(libgcj.so.7rh) at java.lang.Class.newInstance(libgcj.so.7rh) at org.apache.xerces.impl.dv.ObjectFactory.newInstance(xerces-j2-2.7.1.jar.so) at org.apache.xerces.impl.dv.SchemaDVFactory.getInstance(xerces-j2-2.7.1.jar.so) at org.apache.xerces.impl.dv.SchemaDVFactory.getInstance(xerces-j2-2.7.1.jar.so) at org.apache.xerces.impl.xs.SchemaGrammar$BuiltinSchemaGrammar.(Unknown Source) at org.apache.xerces.impl.xs.SchemaGrammar.(Unknown Source) at java.lang.Class.initializeClass(libgcj.so.7rh) at org.apache.xerces.impl.xs.XMLSchemaValidator.(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.configurePipeline(Unknown Source) at org.apache.xerces.parsers.XIncludeAwareParserConfiguration.configurePipeline(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) at org.apache.commons.digester.Digester.parse(jakarta-commons-digester-1.7.jar.so) at org.apache.struts.action.ActionServlet.parseModuleConfigFile(struts-1.2.8.jar.so) at org.apache.struts.action.ActionServlet.initModuleConfig(struts-1.2.8.jar.so) at org.apache.struts.action.ActionServlet.init(struts-1.2.8.jar.so) at org.apache.webapp.admin.ApplicationServlet.init(ApplicationServlet.java:105) at javax.servlet.GenericServlet.init(tomcat5-servlet-2.4-api-5.5.17.jar.so) at org.apache.catalina.core.StandardWrapper.loadServlet(catalina-5.5.17.jar.so8m262s.so) at org.apache.catalina.core.StandardWrapper.allocate(catalina-5.5.17.jar.so8m262s.so) at org.apache.catalina.core.ApplicationDispatcher.invoke(catalina-5.5.17.jar.so8m262s.so) at org.apache.catalina.core.ApplicationDispatcher.doInclude(catalina-5.5.17.jar.so8m262s.so) at org.apache.catalina.core.ApplicationDispatcher.include(catalina-5.5.17.jar.so8m262s.so) at admin.login_jsp._jspService(catalina-admin-5.5.17.jar.so) at org.apache.jasper.runtime.HttpJspBase.service(jasper5-runtime-5.5.17.jar.so) at javax.servlet.http.HttpServlet.service(tomcat5-servlet-2.4-api-5.5.17.jar.so) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(catalina-5.5.17.jar.so8m262s.so) at org.apache.catalina.core.ApplicationFilterChain.doFilter(catalina-5.5.17.jar.so8m262s.so) at org.apache.catalina.core.ApplicationDispatcher.invoke(catalina-5.5.17.jar.so8m262s.so) at org.apache.catalina.core.ApplicationDispatcher.processRequest(catalina-5.5.17.jar.so8m262s.so) at org.apache.catalina.core.ApplicationDispatcher.doForward(catalina-5.5.17.jar.so8m262s.so) at org.apache.catalina.core.ApplicationDispatcher.forward(catalina-5.5.17.jar.so8m262s.so) at org.apache.catalina.authenticator.FormAuthenticator.forwardToLoginPage(catalina-5.5.17.jar.so8m262s.so) at org.apache.catalina.authenticator.FormAuthenticator.authenticate(catalina-5.5.17.jar.so8m262s.so) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(catalina-5.5.17.jar.so8m262s.so) at org.apache.catalina.core.StandardHostValve.invoke(catalina-5.5.17.jar.so8m262s.so) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(catalina-5.5.17.jar.so8m262s.so) at org.apache.catalina.connector.CoyoteAdapter.service(catalina-5.5.17.jar.so8m262s.so) at org.apache.coyote.http11.Http11Processor.process(tomcat-http-5.5.17.jar.so) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(tomcat-http-5.5.17.jar.so) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(tomcat-util-5.5.17.jar.so) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(tomcat-util-5.5.17.jar.so) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(tomcat-util-5.5.17.jar.so) at java.lang.Thread.run(libgcj.so.7rh) Caused by: java.lang.IncompatibleClassChangeError: org.apache.xerces.impl.xpath.regex.Token$ModifierToken at java.lang.VMClassLoader.defineClass(libgcj.so.7rh) at java.lang.ClassLoader.defineClass(libgcj.so.7rh) at java.security.SecureClassLoader.defineClass(libgcj.so.7rh) at java.net.URLClassLoader.findClass(libgcj.so.7rh) at gnu.gcj.runtime.BootClassLoader.bootLoadClass(libgcj.so.7rh) at java.lang.VMClassLoader.loadClass(libgcj.so.7rh) at java.lang.ClassLoader.loadClass(libgcj.so.7rh) at java.lang.ClassLoader.loadClass(libgcj.so.7rh) at java.lang.Class.initializeClass(libgcj.so.7rh) ...53 more 25-Jul-06 12:23:34 PM org.apache.catalina.core.ApplicationContext log INFO: Marking servlet action as unavailable 25-Jul-06 12:23:34 PM org.apache.catalina.core.ApplicationDispatcher invoke SEVERE: Allocate exception for servlet action javax.servlet.UnavailableException: org.apache.xerces.impl.xpath.regex.RegularExpression at org.apache.struts.action.ActionServlet.init(struts-1.2.8.jar.so) at org.apache.webapp.admin.ApplicationServlet.init(ApplicationServlet.java:105) at javax.servlet.GenericServlet.init(tomcat5-servlet-2.4-api-5.5.17.jar.so) at org.apache.catalina.core.StandardWrapper.loadServlet(catalina-5.5.17.jar.so8m262s.so) at org.apache.catalina.core.StandardWrapper.allocate(catalina-5.5.17.jar.so8m262s.so) at org.apache.catalina.core.ApplicationDispatcher.invoke(catalina-5.5.17.jar.so8m262s.so) at org.apache.catalina.core.ApplicationDispatcher.doInclude(catalina-5.5.17.jar.so8m262s.so) at org.apache.catalina.core.ApplicationDispatcher.include(catalina-5.5.17.jar.so8m262s.so) at admin.login_jsp._jspService(catalina-admin-5.5.17.jar.so) at org.apache.jasper.runtime.HttpJspBase.service(jasper5-runtime-5.5.17.jar.so) at javax.servlet.http.HttpServlet.service(tomcat5-servlet-2.4-api-5.5.17.jar.so) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(catalina-5.5.17.jar.so8m262s.so) at org.apache.catalina.core.ApplicationFilterChain.doFilter(catalina-5.5.17.jar.so8m262s.so) at org.apache.catalina.core.ApplicationDispatcher.invoke(catalina-5.5.17.jar.so8m262s.so) at org.apache.catalina.core.ApplicationDispatcher.processRequest(catalina-5.5.17.jar.so8m262s.so) at org.apache.catalina.core.ApplicationDispatcher.doForward(catalina-5.5.17.jar.so8m262s.so) at org.apache.catalina.core.ApplicationDispatcher.forward(catalina-5.5.17.jar.so8m262s.so) at org.apache.catalina.authenticator.FormAuthenticator.forwardToLoginPage(catalina-5.5.17.jar.so8m262s.so) at org.apache.catalina.authenticator.FormAuthenticator.authenticate(catalina-5.5.17.jar.so8m262s.so) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(catalina-5.5.17.jar.so8m262s.so) at org.apache.catalina.core.StandardHostValve.invoke(catalina-5.5.17.jar.so8m262s.so) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(catalina-5.5.17.jar.so8m262s.so) at org.apache.catalina.connector.CoyoteAdapter.service(catalina-5.5.17.jar.so8m262s.so) at org.apache.coyote.http11.Http11Processor.process(tomcat-http-5.5.17.jar.so) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(tomcat-http-5.5.17.jar.so) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(tomcat-util-5.5.17.jar.so) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(tomcat-util-5.5.17.jar.so) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(tomcat-util-5.5.17.jar.so) at java.lang.Thread.run(libgcj.so.7rh) 25-Jul-06 12:23:34 PM org.apache.catalina.core.ApplicationDispatcher invoke SEVERE: Servlet.service() for servlet admin.login_jsp threw exception javax.servlet.UnavailableException: org.apache.xerces.impl.xpath.regex.RegularExpression at org.apache.struts.action.ActionServlet.init(struts-1.2.8.jar.so) at org.apache.webapp.admin.ApplicationServlet.init(ApplicationServlet.java:105) at javax.servlet.GenericServlet.init(tomcat5-servlet-2.4-api-5.5.17.jar.so) at org.apache.catalina.core.StandardWrapper.loadServlet(catalina-5.5.17.jar.so8m262s.so) at org.apache.catalina.core.StandardWrapper.allocate(catalina-5.5.17.jar.so8m262s.so) at org.apache.catalina.core.ApplicationDispatcher.invoke(catalina-5.5.17.jar.so8m262s.so) at org.apache.catalina.core.ApplicationDispatcher.doInclude(catalina-5.5.17.jar.so8m262s.so) at org.apache.catalina.core.ApplicationDispatcher.include(catalina-5.5.17.jar.so8m262s.so) at admin.login_jsp._jspService(catalina-admin-5.5.17.jar.so) at org.apache.jasper.runtime.HttpJspBase.service(jasper5-runtime-5.5.17.jar.so) at javax.servlet.http.HttpServlet.service(tomcat5-servlet-2.4-api-5.5.17.jar.so) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(catalina-5.5.17.jar.so8m262s.so) at org.apache.catalina.core.ApplicationFilterChain.doFilter(catalina-5.5.17.jar.so8m262s.so) at org.apache.catalina.core.ApplicationDispatcher.invoke(catalina-5.5.17.jar.so8m262s.so) at org.apache.catalina.core.ApplicationDispatcher.processRequest(catalina-5.5.17.jar.so8m262s.so) at org.apache.catalina.core.ApplicationDispatcher.doForward(catalina-5.5.17.jar.so8m262s.so) at org.apache.catalina.core.ApplicationDispatcher.forward(catalina-5.5.17.jar.so8m262s.so) at org.apache.catalina.authenticator.FormAuthenticator.forwardToLoginPage(catalina-5.5.17.jar.so8m262s.so) at org.apache.catalina.authenticator.FormAuthenticator.authenticate(catalina-5.5.17.jar.so8m262s.so) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(catalina-5.5.17.jar.so8m262s.so) at org.apache.catalina.core.StandardHostValve.invoke(catalina-5.5.17.jar.so8m262s.so) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(catalina-5.5.17.jar.so8m262s.so) at org.apache.catalina.connector.CoyoteAdapter.service(catalina-5.5.17.jar.so8m262s.so) at org.apache.coyote.http11.Http11Processor.process(tomcat-http-5.5.17.jar.so) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(tomcat-http-5.5.17.jar.so) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(tomcat-util-5.5.17.jar.so) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(tomcat-util-5.5.17.jar.so) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(tomcat-util-5.5.17.jar.so) at java.lang.Thread.run(libgcj.so.7rh) 25-Jul-06 12:23:34 PM org.apache.catalina.core.ApplicationContext log INFO: Marking servlet admin.login_jsp as unavailable 25-Jul-06 12:23:34 PM org.apache.catalina.authenticator.FormAuthenticator forwardToLoginPage WARNING: Unexpected error forwarding to login page javax.servlet.UnavailableException: org.apache.xerces.impl.xpath.regex.RegularExpression at org.apache.struts.action.ActionServlet.init(struts-1.2.8.jar.so) at org.apache.webapp.admin.ApplicationServlet.init(ApplicationServlet.java:105) at javax.servlet.GenericServlet.init(tomcat5-servlet-2.4-api-5.5.17.jar.so) at org.apache.catalina.core.StandardWrapper.loadServlet(catalina-5.5.17.jar.so8m262s.so) at org.apache.catalina.core.StandardWrapper.allocate(catalina-5.5.17.jar.so8m262s.so) at org.apache.catalina.core.ApplicationDispatcher.invoke(catalina-5.5.17.jar.so8m262s.so) at org.apache.catalina.core.ApplicationDispatcher.doInclude(catalina-5.5.17.jar.so8m262s.so) at org.apache.catalina.core.ApplicationDispatcher.include(catalina-5.5.17.jar.so8m262s.so) at admin.login_jsp._jspService(catalina-admin-5.5.17.jar.so) at org.apache.jasper.runtime.HttpJspBase.service(jasper5-runtime-5.5.17.jar.so) at javax.servlet.http.HttpServlet.service(tomcat5-servlet-2.4-api-5.5.17.jar.so) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(catalina-5.5.17.jar.so8m262s.so) at org.apache.catalina.core.ApplicationFilterChain.doFilter(catalina-5.5.17.jar.so8m262s.so) at org.apache.catalina.core.ApplicationDispatcher.invoke(catalina-5.5.17.jar.so8m262s.so) at org.apache.catalina.core.ApplicationDispatcher.processRequest(catalina-5.5.17.jar.so8m262s.so) at org.apache.catalina.core.ApplicationDispatcher.doForward(catalina-5.5.17.jar.so8m262s.so) at org.apache.catalina.core.ApplicationDispatcher.forward(catalina-5.5.17.jar.so8m262s.so) at org.apache.catalina.authenticator.FormAuthenticator.forwardToLoginPage(catalina-5.5.17.jar.so8m262s.so) at org.apache.catalina.authenticator.FormAuthenticator.authenticate(catalina-5.5.17.jar.so8m262s.so) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(catalina-5.5.17.jar.so8m262s.so) at org.apache.catalina.core.StandardHostValve.invoke(catalina-5.5.17.jar.so8m262s.so) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(catalina-5.5.17.jar.so8m262s.so) at org.apache.catalina.connector.CoyoteAdapter.service(catalina-5.5.17.jar.so8m262s.so) at org.apache.coyote.http11.Http11Processor.process(tomcat-http-5.5.17.jar.so) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(tomcat-http-5.5.17.jar.so) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(tomcat-util-5.5.17.jar.so) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(tomcat-util-5.5.17.jar.so) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(tomcat-util-5.5.17.jar.so) at java.lang.Thread.run(libgcj.so.7rh) 25-Jul-06 12:23:37 PM org.apache.catalina.core.ApplicationDispatcher invoke WARNING: Servlet admin.login_jsp is currently unavailable 25-Jul-06 12:23:44 PM org.apache.catalina.core.ApplicationDispatcher invoke WARNING: Servlet admin.login_jsp is currently unavailable From mark at klomp.org Sat Jul 29 17:36:36 2006 From: mark at klomp.org (Mark Wielaard) Date: Sat, 29 Jul 2006 19:36:36 +0200 Subject: [fedora-java] gcjwebplugin has landed in Rawhide In-Reply-To: <44C6723A.4090508@redhat.com> References: <44C6723A.4090508@redhat.com> Message-ID: <1154194597.5929.67.camel@dijkstra.wildebeest.org> Hi, On Tue, 2006-07-25 at 15:34 -0400, Thomas Fitzsimmons wrote: > I closed the long-standing "Inclusion of gcjwebplugin" bug: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=127537 So cool. And it works nicely. Good work! > The GNU Classpath AWT and Swing code was in a state of flux when the backport > that included gcjwebplugin was done (because of a large Java2D rewrite to make > the Cairo backend the default), so there are some regressions in AWT and Swing > applications for FC6test2. > > My post-test2 plan for gcjwebplugin is to gage the reaction of Rawhide users, > and also to do another GUI backport from GNU Classpath HEAD to Fedora's libgcj, > to fix the AWT and Swing regressions. My own ideas/plans are as follows: - GNU Classpath branched for 0.92 last week and a full release is expected early next week. - There is already a first try of a merge of this new version with libgcj head: http://gcc.gnu.org/ml/java/2006-07/msg00057.html (If you want to try this, please read the whole thread, there are some, ehe, subtleties involving svn, merge and creating patches...) - I will try to update that merge to the new classpath-0_92-branch-point today. And hopefully get it committed during the weekend. - When GNU Classpath 0.92 releases get merge updated with last minute release critical patches. - Merge current backport with the refreshed libgcj trunk import. For that last point it would be really nice to have a svn branch in upstream gcc. Since I am sure we could share some work with other distributions. Matthias (CCed) already tried to sync the Debian gcc packages with the Fedora packages, but we had some trouble getting a working patch out of the srpm. Hopefully we can get the Fedora patch set into svn somehow so we can get svn merge to help us with the update. Are there any specific deadlines for when any of our plans need to be done? - gcc 4.2 branch (unknown) - deadline for libgcj/classpath import. - FC6 Test3 Development Freeze (August 23) - deadline for libgcj backport. But probably earlier if we need to do a mass rebuild of all pacakges depending on the new libgcj. Any parties/persons that we need to keep in the loop/that we need to get approval of for any of the above? > If the reaction turns out to be overly > negative, even after the new AWT and Swing backport, we can always make > gcjwebplugin not installed by default, for FC6test3. For FC6test2 though, it is > installed by default if the Internet group is selected. Is there a security group for Fedora? If so, maybe they can take a look at the run plugin warning dialogs and give some feedback on it. Cheers, Mark From aph at redhat.com Sun Jul 30 09:10:17 2006 From: aph at redhat.com (Andrew Haley) Date: Sun, 30 Jul 2006 10:10:17 +0100 Subject: [fedora-java] gcjwebplugin has landed in Rawhide In-Reply-To: <1154194597.5929.67.camel@dijkstra.wildebeest.org> References: <44C6723A.4090508@redhat.com> <1154194597.5929.67.camel@dijkstra.wildebeest.org> Message-ID: <17612.30585.326596.695389@zebedee.pink> Mark Wielaard writes: > Any parties/persons that we need to keep in the loop/that we need to get > approval of for any of the above? We've got to get the support of the {lib}gcj maintainers and Fedora releng. According to the Fedora schedule, the FC6 feature freeze has already happened, so we can't add anything new. We can fix bugs, however. Merging Classpath into Test 3 should be done if we are sure that it fixes important bugs and doesn't cause regressions. We already know that there were some regressions with the Test 2 merge, for example, and we have a chance to fix them. But Test 3 is too late to be causing regressions. However, if we come up with a list of important bugs that will be fixed by a bulk merge, and we can convince ourselves that there won't be serious regressions, then we could do it. Andrew. From green at redhat.com Sun Jul 30 18:25:02 2006 From: green at redhat.com (Anthony Green) Date: Sun, 30 Jul 2006 11:25:02 -0700 Subject: [fedora-java] fc6 extras java status Message-ID: <1154283903.2886.22.camel@localhost.localdomain> Things are a little ugly in fc6 extras java land... * Azureus makes my computer practically unusable because of libgcj's new SecureRandom implementation. I've filed a bug for a work around here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=200653 Mark tells me this is the root cause of some crypto test timeout problems on the autobuilder as well. Casey says that this same code doesn't seem to have a problem on jamvm. * RSSOwl no longer fails to start because of the zip problem (thanks tromey!), but now crashes in _Jv_ClassReader::checkExtends (super = 0x3). I'm rebuilding libgcj with -O0 -g3 to debug. * I've updated jogl to jsr231 1.0 beta 5. The good news is that it builds sans patching! The bad news is that demos crash the X server (like, try resizing the gears demo). I think this is an X problem, so I'm going to push this out anyways because the latest WW2D (and "WW2D plus one", which looks awesome -- http://www.alpix.com/3d/worldwin/WW2d_Java.html) use this version of the jogl API. * kawa is fine. AG From mark at klomp.org Sun Jul 30 21:44:44 2006 From: mark at klomp.org (Mark Wielaard) Date: Sun, 30 Jul 2006 23:44:44 +0200 Subject: [fedora-java] fc6 extras java status In-Reply-To: <1154283903.2886.22.camel@localhost.localdomain> References: <1154283903.2886.22.camel@localhost.localdomain> Message-ID: <1154295885.4853.46.camel@dijkstra.wildebeest.org> On Sun, 2006-07-30 at 11:25 -0700, Anthony Green wrote: > * Azureus makes my computer practically unusable because of libgcj's new > SecureRandom implementation. I've filed a bug for a work around here: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=200653 > Mark tells me this is the root cause of some crypto test timeout > problems on the autobuilder as well. Casey says that this same code > doesn't seem to have a problem on jamvm. It does seem to be not very efficient on my version of jamvm. I just committed the following to classpath which works pretty nicely: 2006-07-30 Mark Wielaard * resource/java/security/classpath.security: Add /dev/urandom as default securerandom.source. This will be part of 0.92. Cheers, Mark diff -u -r1.2.2.4 classpath.security --- resource/java/security/classpath.security 23 Jul 2006 21:28:36 -0000 1.2.2.4 +++ resource/java/security/classpath.security 30 Jul 2006 21:39:58 -0000 @@ -45,3 +45,7 @@ # The VM-wide default callback handler class name. MUST be a subclass of # javax.security.auth.callback.CallbackHandler auth.login.defaultCallbackHandler=gnu.javax.security.auth.callback.DefaultCallbackHandler + +# If this file isn't found we fall back to generating entropy through +# "battling threads". +securerandom.source=file:///dev/urandom From green at redhat.com Mon Jul 31 00:21:12 2006 From: green at redhat.com (Anthony Green) Date: Sun, 30 Jul 2006 17:21:12 -0700 Subject: [fedora-java] fc6 extras java status In-Reply-To: <1154295885.4853.46.camel@dijkstra.wildebeest.org> References: <1154283903.2886.22.camel@localhost.localdomain> <1154295885.4853.46.camel@dijkstra.wildebeest.org> Message-ID: <1154305272.2886.32.camel@localhost.localdomain> On Sun, 2006-07-30 at 23:44 +0200, Mark Wielaard wrote: > It does seem to be not very efficient on my version of jamvm. I just > committed the following to classpath which works pretty nicely: > > 2006-07-30 Mark Wielaard > > * resource/java/security/classpath.security: Add /dev/urandom as > default securerandom.source. > > This will be part of 0.92. rebuild-security-providers from jpackage-utils writes over this file. We need to hack this tool for fedora. AG From david at zarb.org Mon Jul 31 00:35:08 2006 From: david at zarb.org (David Walluck) Date: Sun, 30 Jul 2006 20:35:08 -0400 Subject: [fedora-java] fc6 extras java status In-Reply-To: <1154305272.2886.32.camel@localhost.localdomain> References: <1154283903.2886.22.camel@localhost.localdomain> <1154295885.4853.46.camel@dijkstra.wildebeest.org> <1154305272.2886.32.camel@localhost.localdomain> Message-ID: <44CD503C.90609@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Anthony Green wrote: > rebuild-security-providers from jpackage-utils writes over this file. > We need to hack this tool for fedora. > > AG Actually, it keeps the original file. So all that needs to be done is to update the initial classpath.security file to something more recent. The one from 0.92 would be usable if the security providers are also getting backported for fc6, or in any case, some part of it is usable. - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFEzVA8N5thZBYlTwkRAoI3AJsEwQx/bYjfajoGIQGm+NaasruHUwCgmZPk uDofsaUSn1afs8JhK21M8Qg= =Vy0g -----END PGP SIGNATURE----- From david at zarb.org Mon Jul 31 00:41:30 2006 From: david at zarb.org (David Walluck) Date: Sun, 30 Jul 2006 20:41:30 -0400 Subject: [fedora-java] fc6 extras java status In-Reply-To: <44CD503C.90609@zarb.org> References: <1154283903.2886.22.camel@localhost.localdomain> <1154295885.4853.46.camel@dijkstra.wildebeest.org> <1154305272.2886.32.camel@localhost.localdomain> <44CD503C.90609@zarb.org> Message-ID: <44CD51BA.1050707@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Walluck wrote: > The one from 0.92 would be usable if the security providers are also > getting backported for fc6, or in any case, some part of it is usable. Actually, since rebuild-security-providers replaces the providers only, it doesn't matter what providers are in the initial classpath.security, but the names have changed and number of providers have increased since the version of classpath in gcc 4.1.x. - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFEzVG6N5thZBYlTwkRAnplAJ9xG1Fl4eQHGIOkM1E8Kxt+wW1wCQCfUtS2 d3OElQ6P3nfTuYo0znJkCfY= =Y30w -----END PGP SIGNATURE----- From green at redhat.com Mon Jul 31 05:33:32 2006 From: green at redhat.com (Anthony Green) Date: Sun, 30 Jul 2006 22:33:32 -0700 Subject: [fedora-java] aot-compile-rpm problem Message-ID: <1154324012.2886.38.camel@localhost.localdomain> Hi, On rawhide, when I do a "yum install java-1.4.2-gcj-compat-devel" on my x86-64 system I get both the x86-64 and x86 packages. I suppose the x86 version is written last, because aot-compile-rpm's LIBDIR is set to /usr/lib/gcj instead of /usr/lib64/gcj. This pretty much breaks rpm building. The fix is to make sure I just "yum install java-1.4.2-gcj-compat-devel.x86_64". Is this expected behaviour? I don't remember this being a problem for my in the past. Thanks, AG From green at redhat.com Mon Jul 31 06:54:51 2006 From: green at redhat.com (Anthony Green) Date: Sun, 30 Jul 2006 23:54:51 -0700 Subject: [fedora-java] fc6 extras java status In-Reply-To: <1154283903.2886.22.camel@localhost.localdomain> References: <1154283903.2886.22.camel@localhost.localdomain> Message-ID: <1154328891.2886.45.camel@localhost.localdomain> On Sun, 2006-07-30 at 11:25 -0700, Anthony Green wrote: > * RSSOwl no longer fails to start because of the zip problem (thanks > tromey!), but now crashes in _Jv_ClassReader::checkExtends (super = > 0x3). I'm rebuilding libgcj with -O0 -g3 to debug. This has beaten me. It looks like a hairy class loading bug. Anybody interested in having a look? If so, I'll have to figure out the best way to give you the bits to test with. AG From gbenson at redhat.com Mon Jul 31 07:49:54 2006 From: gbenson at redhat.com (Gary Benson) Date: Mon, 31 Jul 2006 08:49:54 +0100 Subject: [fedora-java] aot-compile-rpm problem In-Reply-To: <1154324012.2886.38.camel@localhost.localdomain> References: <1154324012.2886.38.camel@localhost.localdomain> Message-ID: <20060731074953.GA3741@redhat.com> Anthony Green wrote: > On rawhide, when I do a "yum install java-1.4.2-gcj-compat-devel" on > my x86-64 system I get both the x86-64 and x86 packages. I suppose > the x86 version is written last, because aot-compile-rpm's LIBDIR is > set to /usr/lib/gcj instead of /usr/lib64/gcj. This pretty much > breaks rpm building. > > The fix is to make sure I just "yum install > java-1.4.2-gcj-compat-devel.x86_64". > > Is this expected behaviour? I don't remember this being a problem > for my in the past. Hmmm, a couple of months ago there was a big fuss about making sure multilib -devel packages could be installed simultaneously. I wonder if they changed yum to do something special with -devel packages. Do you have both i386 and x86_64 versions of java-1.4.2-gcj-compat installed? If so, maybe yum sees this and installs both -devel packages too? Cheers, Gary From aph at redhat.com Mon Jul 31 08:54:42 2006 From: aph at redhat.com (Andrew Haley) Date: Mon, 31 Jul 2006 09:54:42 +0100 Subject: [fedora-java] fc6 extras java status In-Reply-To: <1154328891.2886.45.camel@localhost.localdomain> References: <1154283903.2886.22.camel@localhost.localdomain> <1154328891.2886.45.camel@localhost.localdomain> Message-ID: <17613.50514.826364.597536@zebedee.pink> Anthony Green writes: > On Sun, 2006-07-30 at 11:25 -0700, Anthony Green wrote: > > * RSSOwl no longer fails to start because of the zip problem (thanks > > tromey!), but now crashes in _Jv_ClassReader::checkExtends (super = > > 0x3). I'm rebuilding libgcj with -O0 -g3 to debug. > > This has beaten me. It looks like a hairy class loading bug. Anybody > interested in having a look? Yes, definitely. Hairy class loading bugs are the spice of my life. Andrew. From aph at redhat.com Mon Jul 31 08:58:39 2006 From: aph at redhat.com (Andrew Haley) Date: Mon, 31 Jul 2006 09:58:39 +0100 Subject: [fedora-java] aot-compile-rpm problem In-Reply-To: <1154324012.2886.38.camel@localhost.localdomain> References: <1154324012.2886.38.camel@localhost.localdomain> Message-ID: <17613.50751.929133.479102@zebedee.pink> Anthony Green writes: > Hi, > > On rawhide, when I do a "yum install java-1.4.2-gcj-compat-devel" on my > x86-64 system I get both the x86-64 and x86 packages. I suppose the x86 > version is written last, because aot-compile-rpm's LIBDIR is set > to /usr/lib/gcj instead of /usr/lib64/gcj. This pretty much breaks rpm > building. > > The fix is to make sure I just "yum install > java-1.4.2-gcj-compat-devel.x86_64". > > Is this expected behaviour? I don't remember this being a problem for > my in the past. AFAIK it's the default yum behaviour: multilibbed libraries install all arches. That seems a litttle weird, but there it is. Andrew. From green at redhat.com Mon Jul 31 13:50:24 2006 From: green at redhat.com (Anthony Green) Date: Mon, 31 Jul 2006 06:50:24 -0700 Subject: [fedora-java] aot-compile-rpm problem In-Reply-To: <20060731074953.GA3741@redhat.com> References: <1154324012.2886.38.camel@localhost.localdomain> <20060731074953.GA3741@redhat.com> Message-ID: <1154353824.2675.0.camel@localhost.localdomain> On Mon, 2006-07-31 at 08:49 +0100, Gary Benson wrote: > Do you have both i386 and x86_64 versions of java-1.4.2-gcj-compat > installed? No, just the x86_64 version. > If so, maybe yum sees this and installs both -devel > packages too? AG From green at redhat.com Mon Jul 31 14:06:57 2006 From: green at redhat.com (Anthony Green) Date: Mon, 31 Jul 2006 07:06:57 -0700 Subject: [fedora-java] fc6 extras java status In-Reply-To: <17613.50514.826364.597536@zebedee.pink> References: <1154283903.2886.22.camel@localhost.localdomain> <1154328891.2886.45.camel@localhost.localdomain> <17613.50514.826364.597536@zebedee.pink> Message-ID: <1154354817.2675.9.camel@localhost.localdomain> On Mon, 2006-07-31 at 09:54 +0100, Andrew Haley wrote: > > This has beaten me. It looks like a hairy class loading bug. Anybody > > interested in having a look? > > Yes, definitely. Hairy class loading bugs are the spice of my life. Thanks! http://people.redhat.com/~green/FE/devel/rssowl-1.2.1-2.src.rpm AG From green at redhat.com Mon Jul 31 14:22:57 2006 From: green at redhat.com (Anthony Green) Date: Mon, 31 Jul 2006 07:22:57 -0700 Subject: [fedora-java] aot-compile-rpm problem In-Reply-To: <17613.50751.929133.479102@zebedee.pink> References: <1154324012.2886.38.camel@localhost.localdomain> <17613.50751.929133.479102@zebedee.pink> Message-ID: <1154355777.2675.13.camel@localhost.localdomain> On Mon, 2006-07-31 at 09:58 +0100, Andrew Haley wrote: > AFAIK it's the default yum behaviour: multilibbed libraries install > all arches. That seems a litttle weird, but there it is. Gary - do you think aot-compile-rpm could set LIBDIR based in part on the output of "gcj-dbtool -p" ? I think that would let us have identical scripts in both the 32- and 64-bit packages. AG From gbenson at redhat.com Mon Jul 31 14:51:15 2006 From: gbenson at redhat.com (Gary Benson) Date: Mon, 31 Jul 2006 15:51:15 +0100 Subject: [fedora-java] aot-compile-rpm problem In-Reply-To: <1154355777.2675.13.camel@localhost.localdomain> References: <1154324012.2886.38.camel@localhost.localdomain> <17613.50751.929133.479102@zebedee.pink> <1154355777.2675.13.camel@localhost.localdomain> Message-ID: <20060731145114.GB3741@redhat.com> Anthony Green wrote: > On Mon, 2006-07-31 at 09:58 +0100, Andrew Haley wrote: > > AFAIK it's the default yum behaviour: multilibbed libraries > > install all arches. That seems a litttle weird, but there it > > is. > > Gary - do you think aot-compile-rpm could set LIBDIR based in part > on the output of "gcj-dbtool -p" ? I think that would let us have > identical scripts in both the 32- and 64-bit packages. I don't see why not. Though I seem to recall we _used_ to set LIBDIR that way but changed to the present setup to solve a specific problem. gcj-dbtool is in the libgcj rpm: can you have multiple copies of this installed simultaneously? If so, and we do switch, which gcj-dbtool do you get? Cheers, Gary From aph at redhat.com Mon Jul 31 14:54:43 2006 From: aph at redhat.com (Andrew Haley) Date: Mon, 31 Jul 2006 15:54:43 +0100 Subject: [fedora-java] aot-compile-rpm problem In-Reply-To: <20060731145114.GB3741@redhat.com> References: <1154324012.2886.38.camel@localhost.localdomain> <17613.50751.929133.479102@zebedee.pink> <1154355777.2675.13.camel@localhost.localdomain> <20060731145114.GB3741@redhat.com> Message-ID: <17614.6580.17861.194973@zebedee.pink> Gary Benson writes: > Anthony Green wrote: > > On Mon, 2006-07-31 at 09:58 +0100, Andrew Haley wrote: > > > AFAIK it's the default yum behaviour: multilibbed libraries > > > install all arches. That seems a litttle weird, but there it > > > is. > > > > Gary - do you think aot-compile-rpm could set LIBDIR based in part > > on the output of "gcj-dbtool -p" ? I think that would let us have > > identical scripts in both the 32- and 64-bit packages. > > I don't see why not. Though I seem to recall we _used_ to set LIBDIR > that way but changed to the present setup to solve a specific problem. > > gcj-dbtool is in the libgcj rpm: can you have multiple copies of this > installed simultaneously? No. It's in /usr/bin. Andrew. From gbenson at redhat.com Mon Jul 31 15:03:03 2006 From: gbenson at redhat.com (Gary Benson) Date: Mon, 31 Jul 2006 16:03:03 +0100 Subject: [fedora-java] aot-compile-rpm problem In-Reply-To: <17614.6580.17861.194973@zebedee.pink> References: <1154324012.2886.38.camel@localhost.localdomain> <17613.50751.929133.479102@zebedee.pink> <1154355777.2675.13.camel@localhost.localdomain> <20060731145114.GB3741@redhat.com> <17614.6580.17861.194973@zebedee.pink> Message-ID: <20060731150303.GC3741@redhat.com> Andrew Haley wrote: > Gary Benson writes: > > Anthony Green wrote: > > > On Mon, 2006-07-31 at 09:58 +0100, Andrew Haley wrote: > > > > AFAIK it's the default yum behaviour: multilibbed libraries > > > > install all arches. That seems a litttle weird, but there it > > > > is. > > > > > > Gary - do you think aot-compile-rpm could set LIBDIR based in > > > part on the output of "gcj-dbtool -p" ? I think that would let > > > us have identical scripts in both the 32- and 64-bit packages. > > > > I don't see why not. Though I seem to recall we _used_ to set > > LIBDIR that way but changed to the present setup to solve a > > specific problem. > > > > gcj-dbtool is in the libgcj rpm: can you have multiple copies of > > this installed simultaneously? > > No. It's in /usr/bin. Really? So no simultaneous libgcj.i386 and libgcj.x86_64 installs? Cheers, Gary From aph at redhat.com Mon Jul 31 15:12:43 2006 From: aph at redhat.com (Andrew Haley) Date: Mon, 31 Jul 2006 16:12:43 +0100 Subject: [fedora-java] aot-compile-rpm problem In-Reply-To: <20060731150303.GC3741@redhat.com> References: <1154324012.2886.38.camel@localhost.localdomain> <17613.50751.929133.479102@zebedee.pink> <1154355777.2675.13.camel@localhost.localdomain> <20060731145114.GB3741@redhat.com> <17614.6580.17861.194973@zebedee.pink> <20060731150303.GC3741@redhat.com> Message-ID: <17614.7659.677223.57625@zebedee.pink> Gary Benson writes: > Andrew Haley wrote: > > Gary Benson writes: > > > Anthony Green wrote: > > > > On Mon, 2006-07-31 at 09:58 +0100, Andrew Haley wrote: > > > > > AFAIK it's the default yum behaviour: multilibbed libraries > > > > > install all arches. That seems a litttle weird, but there it > > > > > is. > > > > > > > > Gary - do you think aot-compile-rpm could set LIBDIR based in > > > > part on the output of "gcj-dbtool -p" ? I think that would let > > > > us have identical scripts in both the 32- and 64-bit packages. > > > > > > I don't see why not. Though I seem to recall we _used_ to set > > > LIBDIR that way but changed to the present setup to solve a > > > specific problem. > > > > > > gcj-dbtool is in the libgcj rpm: can you have multiple copies of > > > this installed simultaneously? > > > > No. It's in /usr/bin. > > Really? So no simultaneous libgcj.i386 and libgcj.x86_64 installs? No, because libgcj.x86_64 contains both /usr/lib64/* and /usr/lib/* Andrew. From green at redhat.com Mon Jul 31 15:14:26 2006 From: green at redhat.com (Anthony Green) Date: Mon, 31 Jul 2006 08:14:26 -0700 Subject: [fedora-java] aot-compile-rpm problem In-Reply-To: <20060731150303.GC3741@redhat.com> References: <1154324012.2886.38.camel@localhost.localdomain> <17613.50751.929133.479102@zebedee.pink> <1154355777.2675.13.camel@localhost.localdomain> <20060731145114.GB3741@redhat.com> <17614.6580.17861.194973@zebedee.pink> <20060731150303.GC3741@redhat.com> Message-ID: <1154358866.2675.29.camel@localhost.localdomain> On Mon, 2006-07-31 at 16:03 +0100, Gary Benson wrote: > > > gcj-dbtool is in the libgcj rpm: can you have multiple copies of > > > this installed simultaneously? > > > > No. It's in /usr/bin. > > Really? So no simultaneous libgcj.i386 and libgcj.x86_64 installs? It looks like the jar files and man pages conflict so you can't install both at the same time (I tried to force it with "yum install libgcj.i386"). AG From tromey at redhat.com Mon Jul 31 16:41:29 2006 From: tromey at redhat.com (Tom Tromey) Date: Mon, 31 Jul 2006 12:41:29 -0400 Subject: [fedora-java] [poohba@blkpoohba.dyndns.org: Getting java errors when trying to install limewire] In-Reply-To: <20060726011801.GA22575@redhat.com> References: <20060726011801.GA22575@redhat.com> Message-ID: <17614.12985.137437.471414@localhost.localdomain> >>>>> "Andrew" == Andrew Overholt writes: Andrew> We don't expect limewire to work with what I'm assuming is Andrew> FC5, right? Has anyone tried it with rawhide? I haven't tried it in quite a while. >> Exception in thread "main" java.lang.NoClassDefFoundError: >> com.zerog.lax.LAX >> at gnu.java.lang.MainThread.run (libgcj.so.7) >> Caused by: java.lang.ClassNotFoundException: com.zerog.lax.LAX not found >> in This could be a real bug. Or, it could obscure some other linking problem -- for instance if we're missing a class. Someone would need to actually debug a bit to find out :-( Tom From tromey at redhat.com Mon Jul 31 17:09:52 2006 From: tromey at redhat.com (Tom Tromey) Date: Mon, 31 Jul 2006 13:09:52 -0400 Subject: [fedora-java] fc6 extras java status In-Reply-To: <1154295885.4853.46.camel@dijkstra.wildebeest.org> References: <1154283903.2886.22.camel@localhost.localdomain> <1154295885.4853.46.camel@dijkstra.wildebeest.org> Message-ID: <17614.14688.207215.101536@localhost.localdomain> >>>>> "Mark" == Mark Wielaard writes: Mark> 2006-07-30 Mark Wielaard Mark> * resource/java/security/classpath.security: Add /dev/urandom as Mark> default securerandom.source. Mark> This will be part of 0.92. This should probably go in GCC svn as soon as possible. Also we should pull it into the FC6 RPM. Tom From aph at redhat.com Mon Jul 31 17:20:26 2006 From: aph at redhat.com (Andrew Haley) Date: Mon, 31 Jul 2006 18:20:26 +0100 Subject: [fedora-java] fc6 extras java status In-Reply-To: <1154354817.2675.9.camel@localhost.localdomain> References: <1154283903.2886.22.camel@localhost.localdomain> <1154328891.2886.45.camel@localhost.localdomain> <17613.50514.826364.597536@zebedee.pink> <1154354817.2675.9.camel@localhost.localdomain> Message-ID: <17614.15322.579966.580102@zebedee.pink> Anthony Green writes: > On Mon, 2006-07-31 at 09:54 +0100, Andrew Haley wrote: > > > This has beaten me. It looks like a hairy class loading bug. Anybody > > > interested in having a look? > > > > Yes, definitely. Hairy class loading bugs are the spice of my life. > > Thanks! > > http://people.redhat.com/~green/FE/devel/rssowl-1.2.1-2.src.rpm The real exception is java.lang.ClassNotFoundException at 2aaab4c55a50 { java.lang.Throwable ex = null, java.lang.VMThrowable vmState = 0x2aaab28a8530, [Ljava.lang.StackTraceElement; stackTrace = null, java.lang.Throwable cause = 0x2aaab4c55a50, java.lang.String detailMessage = "org.eclipse.core.commands.common.EventManager not found in gnu.gcj.runtime.SystemClassLoader{urls=[file:/usr/share/java/rssowl.jar,file:/usr/share/java/xerces-j2.jar,file:/usr/share/java/itext.jar,file:/usr/share/eclipse/plugins/org.eclipse.core.runtime_3.2.0.v20060603.jar,file:/usr/share/eclipse/plugins/org.eclipse.ui.forms_3.2.0.v20060602.jar,file:/usr/share/java/swt-gtk-3.2.jar,file:/usr/share/java/commons-logging.jar,file:/usr/share/eclipse/plugins/org.eclipse.jface_3.2.0.I20060605-1400.jar,file:/usr/share/java/jdom.jar,file:/usr/share/java/commons-httpclient.jar,file:/usr/share/java/commons-codec.jar,file:/usr/share/java/glib0.2.jar,file:/usr/share/java/gconf2.12.jar,file:/usr/share/java/gtk2.8.jar,file:/usr/share/java/], parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}", } org.eclipse.core.commands.common.EventManager is in /usr/share/eclipse/plugins/org.eclipse.core.commands_3.2.0.I20060605-1400.jar Yous RSSowl start line should look like exec java -Djava.library.path=/usr/lib64/ -cp /usr/share/java/rssowl.jar:/usr/share/java/xerces-j2.jar:/usr/share/java/itext.jar:/usr/share/eclipse/plugins/org.eclipse.core.runtime_3.2.0.v20060603.jar:/usr/share/eclipse/plugins/org.eclipse.core.commands_3.2.0.I20060605-1400.jar:/usr/share/eclipse/plugins/org.eclipse.ui.forms_3.2.0.v20060602.jar:/usr/share/java/swt-gtk-3.2.jar:/usr/share/java/commons-logging.jar:/usr/share/eclipse/plugins/org.eclipse.jface_3.2.0.I20060605-1400.jar:/usr/share/eclipse/plugins/com.ibm.icu_3.4.4.1.jar:/usr/share/eclipse/plugins/org.eclipse.equinox.common_3.2.0.v20060603.jar:/usr/share/java/jdom.jar:/usr/share/java/commons-httpclient.jar:/usr/share/java/commons-codec.jar:/usr/share/java/glib0.2.jar:/usr/share/java/gconf2.12.jar:/usr/share/java/gtk2.8.jar:/usr/share/java/ net.sourceforge.rssowl.controller.RSSOwlLoader "$@" From green at redhat.com Mon Jul 31 18:09:13 2006 From: green at redhat.com (Anthony Green) Date: Mon, 31 Jul 2006 11:09:13 -0700 Subject: [fedora-java] fc6 extras java status In-Reply-To: <17614.15322.579966.580102@zebedee.pink> References: <1154283903.2886.22.camel@localhost.localdomain> <1154328891.2886.45.camel@localhost.localdomain> <17613.50514.826364.597536@zebedee.pink> <1154354817.2675.9.camel@localhost.localdomain> <17614.15322.579966.580102@zebedee.pink> Message-ID: <1154369353.2699.0.camel@localhost.localdomain> On Mon, 2006-07-31 at 18:20 +0100, Andrew Haley wrote: > Yous RSSowl start line should look like Awesome, thanks. Did you see a NullPointer exception, like I did? In any case, rssowl appears to be working well now (modulo old feed finding bug - probably a regexp issue). AG From aph at redhat.com Mon Jul 31 18:35:33 2006 From: aph at redhat.com (Andrew Haley) Date: Mon, 31 Jul 2006 19:35:33 +0100 Subject: [fedora-java] fc6 extras java status In-Reply-To: <1154369353.2699.0.camel@localhost.localdomain> References: <1154283903.2886.22.camel@localhost.localdomain> <1154328891.2886.45.camel@localhost.localdomain> <17613.50514.826364.597536@zebedee.pink> <1154354817.2675.9.camel@localhost.localdomain> <17614.15322.579966.580102@zebedee.pink> <1154369353.2699.0.camel@localhost.localdomain> Message-ID: <17614.19829.164894.622654@zebedee.pink> From aph at redhat.com Mon Jul 31 18:35:54 2006 From: aph at redhat.com (Andrew Haley) Date: Mon, 31 Jul 2006 19:35:54 +0100 Subject: [fedora-java] fc6 extras java status In-Reply-To: <1154369353.2699.0.camel@localhost.localdomain> References: <1154283903.2886.22.camel@localhost.localdomain> <1154328891.2886.45.camel@localhost.localdomain> <17613.50514.826364.597536@zebedee.pink> <1154354817.2675.9.camel@localhost.localdomain> <17614.15322.579966.580102@zebedee.pink> <1154369353.2699.0.camel@localhost.localdomain> Message-ID: <17614.19850.975025.832179@zebedee.pink> Anthony Green writes: > On Mon, 2006-07-31 at 18:20 +0100, Andrew Haley wrote: > > Yous RSSowl start line should look like > > Awesome, thanks. Did you see a NullPointer exception, like I did? Yes. > In any case, rssowl appears to be working well now (modulo old feed > finding bug - probably a regexp issue). Good. Andrew. From green at redhat.com Mon Jul 31 19:01:06 2006 From: green at redhat.com (Anthony Green) Date: Mon, 31 Jul 2006 12:01:06 -0700 Subject: [fedora-java] ssl connections, cacerts Message-ID: <1154372466.2699.18.camel@localhost.localdomain> Now that rssowl is running (thanks aph), I wanted to see if https rss feeds would work (like those provided by bugzilla). Our classpath.security file is messed up, but I think fitzsim just fixed this: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=200701 When I fix it manually, and try to access an https rss feed, I get... Exception in thread "Load Feed Thread" org.apache.commons.httpclient.HttpClientError: java.security.KeyStoreException: java.io.FileNotFoundException: /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre/lib/security/cacerts (No such file or directory) at net.sourceforge.rssowl.dao.ssl.EasySSLProtocolSocketFactory.createEasySSLContext(Unknown Source) at net.sourceforge.rssowl.dao.ssl.EasySSLProtocolSocketFactory.getSSLContext(Unknown Source) at net.sourceforge.rssowl.dao.ssl.EasySSLProtocolSocketFactory.createSocket(Unknown Source) at org.apache.commons.httpclient.HttpConnection.open(jakarta-commons-httpclient-3.0.jar.so) at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(jakarta-commons-httpclient-3.0.jar.so) at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(jakarta-commons-httpclient-3.0.jar.so) at org.apache.commons.httpclient.HttpClient.executeMethod(jakarta-commons-httpclient-3.0.jar.so) at org.apache.commons.httpclient.HttpClient.executeMethod(jakarta-commons-httpclient-3.0.jar.so) at net.sourceforge.rssowl.dao.ConnectionManager.openConnection(Unknown Source) at net.sourceforge.rssowl.dao.ConnectionManager.connect(Unknown Source) at net.sourceforge.rssowl.dao.ConnectionManager.connect(Unknown Source) at net.sourceforge.rssowl.dao.NewsfeedFactory.initXmlDocument(Unknown Source) at net.sourceforge.rssowl.dao.NewsfeedFactory.(Unknown Source) at net.sourceforge.rssowl.dao.NewsfeedFactory.(Unknown Source) at net.sourceforge.rssowl.controller.thread.FeedLoader.run(Unknown Source) We don't have a cacerts file. How is this supposed to work? AG From tromey at redhat.com Mon Jul 31 20:34:48 2006 From: tromey at redhat.com (Tom Tromey) Date: Mon, 31 Jul 2006 14:34:48 -0600 Subject: [fedora-java] gcjwebplugin has landed in Rawhide In-Reply-To: <1154194597.5929.67.camel@dijkstra.wildebeest.org> References: <44C6723A.4090508@redhat.com> <1154194597.5929.67.camel@dijkstra.wildebeest.org> Message-ID: <17614.26984.915483.80585@localhost.localdomain> >>>>> "Mark" == Mark Wielaard writes: Mark> For that last point it would be really nice to have a svn branch in Mark> upstream gcc. Since I am sure we could share some work with other Mark> distributions. Matthias (CCed) already tried to sync the Debian gcc Mark> packages with the Fedora packages, but we had some trouble getting a Mark> working patch out of the srpm. Hopefully we can get the Fedora patch set Mark> into svn somehow so we can get svn merge to help us with the update. Jakub had asked for a patch rather than a branch, so that's what we did. But really we can do both -- I wish I'd thought of this when doing the merge. That is, we can make a branch, do stuff there, and then just diff it against the RH 4.1 branch whenever we need to provide Jakub with an updated patch. Tom From green at redhat.com Mon Jul 31 21:22:47 2006 From: green at redhat.com (Anthony Green) Date: Mon, 31 Jul 2006 14:22:47 -0700 Subject: [fedora-java] Re: ssl connections, cacerts In-Reply-To: <2180DD9F-E218-4149-B687-B0CD440B615A@gnu.org> References: <1154372466.2699.18.camel@localhost.localdomain> <2180DD9F-E218-4149-B687-B0CD440B615A@gnu.org> Message-ID: <1154380967.2699.29.camel@localhost.localdomain> On Mon, 2006-07-31 at 13:24 -0700, Casey Marshall wrote: > Most GNU/Linux distributions have packages for a list of root > certificates, usually as just a bunch of separate PEM files. Does > Fedora have something like that? Yes. It looks like openssl ships with certificates. kdelibs does as well. Perhaps there are others. > If so, one good way to fix this > would be to generate a cacerts file (using gkeytool) that contains > the same list of certificates, and add that to the GCJ RPM. It is > somewhat preferable for distributions to figure out which root > certificates they want to use, than for Classpath to arbitrarily > decide what certificates to include, IMO. Sounds good. This should probably go in the java-1.4.2-gcj-compat package (our JDK compatibility layer on top of gcj). We could simply "BuildRequire" openssl to generate and package the cacerts files. > Does that make sense? I can explain how to generate such a cacerts > file from a bunch of separate certificates, if you like. That would be great. I've never run gkeytool before. > Additionally, loading cacerts isn't even necessary with Classpath: > Jessie uses an internal list of root certificates (approximately the > same list you'll find by default in e.g. Firefox) if no other > certificates are provided. Nice to see that the RSSOwl people had to > make this crap so "Easy." A bug (or maybe just some harsh words) > upstream is also advisable. Ok. Thanks, AG From green at redhat.com Mon Jul 31 21:39:25 2006 From: green at redhat.com (Anthony Green) Date: Mon, 31 Jul 2006 14:39:25 -0700 Subject: [fedora-java] gnu-crypto & jessie Message-ID: <1154381966.2699.33.camel@localhost.localdomain> Do we still need these packages in fc6 or did they get merged into libgcj? Anybody know? Thanks, AG