Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 145240 - Provider for javax.xml.parsers.SAXParserFactory cannot be found
Provider for javax.xml.parsers.SAXParserFactory cannot be found
Product: Fedora
Classification: Fedora
Component: eclipse (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Andrew Overholt
Depends On:
  Show dependency treegraph
Reported: 2005-01-15 15:00 EST by Ellen Shull
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-04-26 16:30:21 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Ellen Shull 2005-01-15 15:00:37 EST
Description of problem:
From eclipse welcome page, click "overview" then "workbench basics".  Nothing
will happen following the second click, and in the terminal from which you
started eclipse (you didn't &>/dev/null, did you?) from you get the message:

Unhandled event loop exception
Provider for javax.xml.parsers.SAXParserFactory cannot be found

For all I know this is actually a gij/gcj problem and should be filed under
gcc4.  If so, my apologies;  please refile in the right place.

Version-Release number of selected component (if applicable):
Comment 1 Andrew Overholt 2005-01-17 15:45:16 EST
Assigning to me.
Comment 2 Andrew Overholt 2005-01-17 15:46:59 EST
_Actually_ assign to me.
Comment 3 Andrew Overholt 2005-01-28 09:45:49 EST
Please try updating to the latest packages (3.0.1_fc-9,
gcc4-4.0.0-0.22, libgcj4-4.0.0-0.22) and see if this happens again. 
One thing to note is that you must have your java alternative set to
java-1.4.2-gcj4-compat like so:

su - -c "update-alternatives --set java \
su - -c "update-alternatives --set javac \
Comment 4 Andrew Overholt 2005-02-02 09:42:02 EST
Any news here?
Comment 5 Ellen Shull 2005-02-03 23:55:37 EST
Sorry, been busy so haven't had time to track rawhide that closely lately.

Just tried again, made sure the gcj4 alternatives were set for java and javac,
and still get the same error.

Now installed:
package ecj is not installed


(Also all the gcc 3 gcj stuff, which I assume is not apropos)

When I originally did the test, I had the Sun JDK 1.5.0, built into rpms from
the jpackage specfile, installed and set as the alternative for all java stuff.
 Now I've updated to jre 1.5.0_01, just used the sun rpm this time (couldn't get
the jpackage spec working on it in the little time I spent), and the behavior is
slightly different; with it set to be the alternative for java, I still get no
response to clicking "workbench basics", but now I don't get the error message
on the console either.  But when I run it with the gcj4 alternatives, I do get
the error message.

Now, I know this all may not be very useful to you, could be because of duelling
java installs or something.  But what bothers me about this is, doesn't Eclipse
normally run fine under the Sun JVM?  And if this build of Eclipse is compiled
like I've heard, why is there the dependency on having the java alternative set?
 Clearly I'm not in possession of the full picture here.

(BTW I'm running the Sun JVM for Azureus.  Which uses SWT too, but chokes so bad
on gcj that it wipes out my config file every time I try it.)
Comment 6 Andrew Overholt 2005-03-08 13:05:39 EST
I can't duplicate this with our new 3.1 M5a builds.  Does it still
happen for you?

The builds of Eclipse we're shipping have both the bytecode and the
corresponding shared objects.  When your java alternative is set to
java-1.4.2-gcj-compat, /usr/bin/java calls gij which interprets the
options in /usr/bin/eclipse to load shared objects instead of
interpreting the bytecode.  This allows us to natively-compile Eclipse
without heavy modifications to Eclipse itself.  The other advantage is
that switching your java alternative to a proprietary JVM should Just
Work with the bytecode that's also shipped.

As for Azureus, I should start testing that - it's popular enough that
it'd be a good showcase app for the free java stuff.
Comment 7 Ellen Shull 2005-03-12 16:16:04 EST
Ok, running today's rawhide, and with a clean install of the java
stuff (as in I blew out *everything* remotely java, to the point of
the java/javac alternatives being gone, then reinstalled), the eclipse
problem is now gone.

I haven't reinstalled Sun JVM to see if it works with that too yet,
but that's somewhat irrelevant from the Fedora POV so I'm closing this
bug now.
Comment 8 Konstantin Ryabitsev 2005-04-23 15:07:28 EDT
Looks like regression in current rawhide. Eclipse currently crashes during
startup, generating the following errors:

with 3.1.0_fc-0.M6.9: http://phy.duke.edu/~icon/misc/eclipse-error.log
with 3.1.0_fc-0.M6.10: http://phy.duke.edu/~icon/misc/eclipse-error-2.log

I can reproduce this on 3 different machines both with pre-existing and
clean-slate environment setups.
Comment 9 Andrew Overholt 2005-04-23 19:48:03 EDT
I think it has something to do with this bug:


Comment 10 Andrew Overholt 2005-04-26 16:30:21 EDT
It looks like the original issue has been fixed.  The startup issues are
actually due to https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=155693 . 
Konstantin, please file any more issues you find (with tomorrow's xml-commons)
there.  Thanks.

Comment 11 Konstantin Ryabitsev 2005-04-27 16:30:41 EDT
Yes indeed, it works great! Thanks for your help.

Note You need to log in before you can comment on or make changes to this bug.