java-devel July 2007

java-devel@lists.fedoraproject.org

11 participants
7 discussions

problem starting native Eclipse on F7
by Raif S. Naffah 26 Jul '07

26 Jul '07

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

2 5

Headaches for sysadmins which Java apps/services
by Joshua Daniel Franklin 26 Jul '07

26 Jul '07

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

2 4

Sun vs "free" java on Fedora
by Joe Desbonnet 25 Jul '07

25 Jul '07

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

3 2

Packaging RXTX
by alcapcom 25 Jul '07

25 Jul '07

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

1 0

JSF application with tomcat and gcj
by Michael Bauschert 23 Jul '07

23 Jul '07

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

3 2

Stranges problem to build plugins with Eclipse 3.3
by alcapcom 22 Jul '07

22 Jul '07

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

3 8

libgcj update troubles on fc6
by Mark Wielaard 06 Jul '07

06 Jul '07

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

1 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

java-devel July 2007