problem starting native Eclipse on F7
by Raif S. Naffah
hello there,
recently i upgraded my system from FC6 to F7. after:
* removing the old eclipse RPMs, deleting usr/lib/eclipse,
usr/share/eclipse, ~/.eclipse, and ~/workspace directories,
* yum groupinstall Eclipse,
* starting eclipse with both gcj (GNU libgcj 4.1.2 20070502 (Red Hat
4.1.2-12)) and Sun's jdk1.5.0_12, i get an error and the log shows:
!ENTRY org.eclipse.core.runtime 2007-07-26 19:02:36.425
!MESSAGE Product org.eclipse.platform.ide could not be found.
!ENTRY org.eclipse.osgi 4 0 2007-07-26 19:02:36.430
!MESSAGE Application error
!STACK 1
java.lang.RuntimeException: No application id has been found.
at org.eclipse.core.internal.runtime.PlatformActivator$1.run(org.eclipse.core.runtime_3.2.0.v20060603.jar.so)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(org.eclipse.osgi_3.2.2.R32x_v20070118.jar.so)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(org.eclipse.osgi_3.2.2.R32x_v20070118.jar.so)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(org.eclipse.osgi_3.2.2.R32x_v20070118.jar.so)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(org.eclipse.osgi_3.2.2.R32x_v20070118.jar.so)
at java.lang.reflect.Method.invoke(libgcj.so.8rh)
at org.eclipse.core.launcher.Main.invokeFramework(startup.jar.so)
at org.eclipse.core.launcher.Main.basicRun(startup.jar.so)
at org.eclipse.core.launcher.Main.run(startup.jar.so)
at org.eclipse.core.launcher.Main.main(startup.jar.so)
any ideas what i'm missing?
TIA + cheers;
rsn
16 years, 2 months
Headaches for sysadmins which Java apps/services
by Joshua Daniel Franklin
Continuing discussion from
"Re: Web-Interface for packages in Fedora: repoview, repowatch, something else?"
https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01093.html
Nicolas Mailhot wrote:
> Le Ven 20 juillet 2007 15:26, Jesse Keating a écrit :
> > All I'm doing is stating my opinions that I've developed over the
> > years of dealing with java applications and hosting java services.
>
> IMHO as soon as we get a working FLOSS JDK the various Red Hat/JBoss
> Java groups need to do get together a few days with Red Hat/Fedora
> distro/Infrastructure team representatives and hash up how Fedora/Red
> Hat Java can be made sysadmin-friendly.
As a sysadmin who deals with Java apps and services, off the top of my
head I'd say the biggest headaches are:
--installing JDKs, which should go away with a Free IcedTea JPackage in Fedora
--process and memory monitoring (which "java" process is 3109 again?)
--runtime dependency resolution (building a /usr/share/java/ CLASSPATH
vs devs bundling all their own jars)
--custom startup scripts for local apps (tomcat has an OK init script)
--duplication of effort between ant/maven build files and RPM spec files
--authorization/authentication (tomcat realms vs unix groups, etc.)
--system-config-securitylevel / iptables for RMI or java.net.*
--on dev machines, updating eclipse (though we just started using the
Jpackage'd
RHEL4 SDK channel which seems pretty stable)
Fedora can't do anything about some of these, but providing a JDK once the
IcedTea issues are resolved will be a big help. And that's waiting on Sun:
http://article.gmane.org/gmane.comp.java.openjdk.distro-packaging.devel/57
Note: classpath.org is currently down, use http://iced-tea.org/ instead.
If anyone has a lot of cycles, wouldn't it be great if ant's <rpm>
task generated
a spec with dependencies as well as built the RPMs? :)
Thanks,
Joshua
16 years, 2 months
Sun vs "free" java on Fedora
by Joe Desbonnet
I'm wondering what the strategy is regarding the existing stack vs the
Sun stack now that it's under a Fedora compatible license. Will the
two initiatives merge sometime in the future? I'm sure this has been
discussed to death in other forums, but can someone who is familiar
with what's going on summarize?
Thanks,
Joe
16 years, 2 months
Packaging RXTX
by alcapcom
Hi all,
I need some help to packaging RXTX from (rxtx.org). This library is
needed to build the Terminal serial line connector of the Eclipse TM
(Target Management) project. The serial connector use only two libs of
RXTX, librxtxParallel.so and librxtxSerial.so.
My first idea was to create a dedicate package for RXTX but the problem
is that RXTX native libs need to live in ...java/lib/arch (it's a JRE
extension), so the package can only be installed for the default JRE.
Martin Oberhuber (the TM Project Lead) have work on a RXTX Eclipse
bundles so that it can be used in Eclipse plugins with a "vanilla" JRE,
nice work! These bundles include the native libs and the classes.
So the second idea is to build RXTX inside the eclipse-rxtx package and
replace the native libs and the .class files before building the RXTX
plugins.
PS: RXTX bundles are not yet available on the web but Martin work on
that with Trent Jarvi (upstream guy) to get an update site on the
rxtx.org web site, see
http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20070129/848211.html
for more details.
Any help would be appreciate.
Thanks,
Alphonse
16 years, 2 months
JSF application with tomcat and gcj
by Michael Bauschert
Hi,
i run a jsf application with tomcat 5.5.23 under Fedora rawhide.
If it comes to compiling the JSPs i get the following errors:
javax.servlet.ServletException: Unable to compile class for JSP:
An error occurred at line: 1 in the jsp file: /index.jsp
The type java.io.Writer cannot be resolved. It is indirectly referenced from required .class files
1: <%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %>
2: <%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %>
3:
4: <f:view>
An error occurred at line: 1 in the jsp file: /index.jsp
The method write(String) is undefined for the type JspWriter
1: <%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %>
2: <%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %>
3:
4: <f:view>
... there are many more such errors - for every line of the JSP
with the following stacktrace within the localhost*.log
Stacktrace:
at org.apache.jasper.compiler.DefaultErrorHandler.javacError(jasper5-compiler-5.5.23.jar.so)
at org.apache.jasper.compiler.ErrorDispatcher.javacError(jasper5-compiler-5.5.23.jar.so)
at org.apache.jasper.compiler.JDTCompiler.generateClass(jasper5-compiler-5.5.23.jar.so)
at org.apache.jasper.compiler.Compiler.compile(jasper5-compiler-5.5.23.jar.so)
at org.apache.jasper.compiler.Compiler.compile(jasper5-compiler-5.5.23.jar.so)
at org.apache.jasper.compiler.Compiler.compile(jasper5-compiler-5.5.23.jar.so)
at org.apache.jasper.JspCompilationContext.compile(jasper5-compiler-5.5.23.jar.so)
at org.apache.jasper.servlet.JspServletWrapper.service(jasper5-compiler-5.5.23.jar.so)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(jasper5-compiler-5.5.23.jar.so)
at org.apache.jasper.servlet.JspServlet.service(jasper5-compiler-5.5.23.jar.so)
at javax.servlet.http.HttpServlet.service(tomcat5-servlet-2.4-api-5.5.23.jar.so)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(catalina-5.5.23.jar.sowsz71d.so)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(catalina-5.5.23.jar.sowsz71d.so)
at org.apache.catalina.core.ApplicationDispatcher.invoke(catalina-5.5.23.jar.sowsz71d.so)
at org.apache.catalina.core.ApplicationDispatcher.processRequest(catalina-5.5.23.jar.sowsz71d.so)
at org.apache.catalina.core.ApplicationDispatcher.doForward(catalina-5.5.23.jar.sowsz71d.so)
at org.apache.catalina.core.ApplicationDispatcher.forward(catalina-5.5.23.jar.sowsz71d.so)
at org.apache.myfaces.context.servlet.ServletExternalContextImpl.dispatch(ServletExternalContextImpl.java:419)
at org.apache.myfaces.application.jsp.JspViewHandlerImpl.renderView(JspViewHandlerImpl.java:211)
at org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:41)
at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:132)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:140)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(catalina-5.5.23.jar.sowsz71d.so)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(catalina-5.5.23.jar.sowsz71d.so)
at org.apache.catalina.core.StandardWrapperValve.invoke(catalina-5.5.23.jar.sowsz71d.so)
at org.apache.catalina.core.StandardContextValve.invoke(catalina-5.5.23.jar.sowsz71d.so)
at org.apache.catalina.core.StandardHostValve.invoke(catalina-5.5.23.jar.sowsz71d.so)
at org.apache.catalina.valves.ErrorReportValve.invoke(catalina-5.5.23.jar.sowsz71d.so)
at org.apache.catalina.core.StandardEngineValve.invoke(catalina-5.5.23.jar.sowsz71d.so)
at org.apache.catalina.connector.CoyoteAdapter.service(catalina-5.5.23.jar.sowsz71d.so)
at org.apache.coyote.http11.Http11Processor.process(tomcat-http-5.5.23.jar.so)
at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(tomcat-http-5.5.23.jar.so)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(tomcat-util-5.5.23.jar.so)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(tomcat-util-5.5.23.jar.so)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(tomcat-util-5.5.23.jar.so)
at java.lang.Thread.run(libgcj.so.8rh)
The same version of the JSP-App is running perfectly fine under a windows tomcat.
The jars in the WEB-INF/lib are:
-rw-r--r-- 1 root root 188671 2007-01-25 17:00 commons-beanutils-1.7.0.jar
-rw-r--r-- 1 root root 46725 2007-01-25 17:00 commons-codec-1.3.jar
-rw-r--r-- 1 root root 559366 2007-01-25 17:00 commons-collections-3.1.jar
-rw-r--r-- 1 root root 168446 2007-01-25 17:00 commons-digester-1.6.jar
-rw-r--r-- 1 root root 112341 2007-01-25 17:00 commons-el-1.0.jar
-rw-r--r-- 1 root root 22379 2007-01-25 17:00 commons-fileupload-1.0.jar
-rw-r--r-- 1 root root 207723 2007-01-25 16:59 commons-lang-2.1.jar
-rw-r--r-- 1 root root 38015 2007-01-25 16:59 commons-logging-1.0.4.jar
-rw-r--r-- 1 root root 138956 2007-03-23 11:38 commons-validator-1.3.1.jar
-rw-r--r-- 1 root root 16923 2007-01-25 16:59 jstl-1.1.0.jar
-rw-r--r-- 1 root root 251988 2007-02-13 10:18 myfaces-api-1.1.5.jar
-rw-r--r-- 1 root root 543521 2007-02-12 10:09 myfaces-impl-1.1.5.jar
-rw-r--r-- 1 root root 65261 2007-01-25 17:00 oro-2.0.8.jar
-rw-r--r-- 1 root root 2941389 2007-06-12 12:28 tomahawk-1.1.6.jar
Any ideas ?
Regards
Michael
16 years, 2 months
Stranges problem to build plugins with Eclipse 3.3
by alcapcom
Hi all,
1) When I build the bundles with the Sun JVM there isn't any problem but
when I try it with GCJ the script don't find
org.eclipse.pde.internal.build.BuildScriptGenerator class?
I have build 3.3 here, I have comment out com.ibm.icu tweak because I
don't have found this bundle in the Fedora sources repo.
BUILD FAILED
/usr/share/eclipse/plugins/org.eclipse.pde.build/scripts/build.xml:24:
The following error occurred while executing this line:
/usr/share/eclipse/plugins/org.eclipse.pde.build/scripts/build.xml:64:
The following error occurred while executing this line:
/usr/share/eclipse/plugins/org.eclipse.pde.build/templates/package-build/customTargets.xml:17:
The following error occurred while executing this line:
/usr/share/eclipse/plugins/org.eclipse.pde.build_3.3.0.v20070612/scripts/genericTargets.xml:85:
Could not create type eclipse.buildScript due to
java.lang.NoClassDefFoundError:
org.eclipse.pde.internal.build.BuildScriptGenerator
2) To build the SDK package for RSE (Remote System Explorer), the FTP,
SSH and telnet based implementation requires org.apache.commons.net and
org.apache.oro bundle provided in the org.eclipse.orbit project. When
the builder try to make the javadoc for both of these bundles, the
builder try to to resolve all the classes recursively to make a full
javadoc, that take many time and as result the eclipse builder crash
because of a out of memory. Can I configure the builder to not create
"full javadoc" or is there a another way to include these deps without
make too many changes on the sources?
PS: RSE need 3.3 for the SSH component.
In advance, thanks,
Alphonse
16 years, 2 months
libgcj update troubles on fc6
by Mark Wielaard
Hi,
Seeing there was an updated package for gcc on my FC6 machine I happily
let the thing update itself. However libgcj breaks while updating:
Updating : libgcj #########################
[1/2]
error: unpacking of archive failed on file /usr/lib/gcj-4.1.2: cpio:
rename
Updated: libgcj.i386 0:4.1.2-13.fc6
Complete!
Notice the happy "Complete!"...
Your resulting gcj environment is now complete borked.
gcj -C Hello.java
Hello.java:0: error: Can't find default package ‘java.lang’. Check the
CLASSPATH environment variable and the access to the archives
1 error
And any attempt to install or update (even after a remove) of libgcj
will fail in the same way. For some reason there are
multiple /usr/lib/gcj-4.1.2;468a1711 dirs (with the part after ; being
some random hex-string) which seem to prevent yum updating or installing
anything.
In the end the only way to get a working install back was to yum remove
libgcj (yes, this takes all the dependencies with it), and then removing
the left over directories
rm -rf /usr/lib/gcj-4.1.2* /usr/lib64/gcj-4.1.2*
And then installing everything again with yum install.
There probably is an easier (and safer) way, and I don't really
understand why this happened in the first place. Comments and ideas
appreciated.
Thanks,
Mark
16 years, 2 months
