java-devel October 2011

java-devel@lists.fedoraproject.org

8 participants
5 discussions

Improvements Eclipse Installation
by sami wagiaalla 15 Feb '12

15 Feb '12

Hi, The way we currently install Eclipse plugins in Fedora is incorrect and somewhat fragile. RPM places all the plugin artifacts in the proper directories. However that does not update the eclipse metadata. This means that until the next time eclipse starts it is unaware of the newly installed plugins. Because the user would normally run Eclipse not as root Eclipse does not have permission to write to the meta data files located in the installation directory. It therefore creates a parallel version in the user's home directory ~/.eclipse. This creates a fragile installation and leads to a whole host of problems. To improve this I have written apatch which runs the Eclipse reconciler during rpm installation. The Eclipse reconciler is an Eclipse application which goes through and checks the installation directories and updates the eclipse metadata with any newly installed plugins. To add support for this in your eclipse package you have to add the following line to your rpm spec file: %_eclipse_pkg [package name] Here is an example from the eclipse-rse spec file for the eclipse-rse-sdk rpm: %package sdk [...] %_eclipse_pkg sdk The above macro expands to the following: %post sdk touch /var/run/eclipse/run-reconciler %postun sdk touch /var/run/eclipse/run-reconciler if [ $1 == 0 ]; then eclipse-reconciler.sh fi %posttrans sdk eclipse-reconciler.sh I apologize if you have experienced instability in Eclipse installations on rawhide, it is probably due to these changes. Please let me know if you have any comments questions or suggestions. I will be filing a request to update the Eclipse packaging guidelines. If you are interested in the details of the work, here is a summary in the form of a patch: http://fpaste.org/pPEC/ Cheers, Sami

2 6

Shared library paths for native linker
by Petr Pisar 23 Jan '12

23 Jan '12

Hello, I have a non-java package (pl) which links to jvm. Build scripts of pl needs to locate directories with libjava.so, libjvm.so etc. and instruct native linker (ld) where to find them (-L option). Current implementation in the pl.spec is uggly (a lot of ad-hoc hacks for each platform which requires tuning time to time <https://bugzilla.redhat.com/show_bug.cgi?id=740897>). So I decided to find ultimate way how to obtain path for linker and Java home directory. Unfortunatelly, I did not find any. So I've written one. You can find it as attachment at the afore-mentioned bug report. Usage is inspired by pkg-config: $ javac JavaConfig.java $ java JavaConfig --home /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre $ java JavaConfig --libs-only-L -L/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server -L/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64 -L/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/../lib/amd64 -L/usr/java/packages/lib/amd64 -L/usr/lib64 -L/lib64 -L/lib -L/usr/lib I can bundle the tool to my `pl' package, but I think it could be helpful for others too. So I'd like to ask Java SIG whether it wants to adopt it (e.g. as a part of JDK). -- Petr

6 9

Tomcat, NSS and OpenJDK
by Adam Young 04 Oct '11

04 Oct '11

Tomcat has a class called "Realm" which is basically a way of managing the set of authentication mechanisms. PKI seems To use an older approach which bypasses the Realm config in Tomcat. I started looking at what it would take to close the distance between the two. In doing so, I found something interesting in the openjdk code base: In /usr/lib/jvm/java-1.6.0/jre/lib/security/java.security, there is a section that looks like this: # # List of providers and their preference orders (see above): # security.provider.1=sun.security.provider.Sun security.provider.2=sun.security.rsa.SunRsaSign ... # the NSS security provider was not enabled for this build; it can be enabled # if NSS (libnss3) is available on the machine. The nss.cfg file may need # editing to reflect the location of the NSS installation. #security.provider.9=sun.security.pkcs11.SunPKCS11 ${java.home}/lib/security/nss.cfg So it seems that Sun had, at least in the past, supported NSS as a Sercurity provider. For the member of the Java team not familiar with NSS (I wasn't) It is the Network Security Services and is the basis for, amongst other things, how Mozilla stores passwords and certificates. PKI makes pretty heavy use of NSS, via the Opensource Java bindings in JSS. This page here has more info: http://download.oracle.com/javase/1.5.0/docs/guide/security/p11guide.html#I… It seems like the Oracle JDK has had support in the past for NSS as a JAAS module. To close the acronym loop with Tomcat, Tomcat has a JAAS Realm class. What this says to me is that, at one point, Java developers could have configured Tomcat to use NSS as the authentication mechanism for an application. This class ships in the file: /usr/lib/jvm/java-1.6.0-openjdk.x86_64/jre/lib/ext/sunpkcs11.jar And The native library is in /usr/lib/jvm/java-1.6.0-openjdk.x86_64/jre/lib/amd64/libj2pkcs11.so So it looks like we might have an additional Java implementation of NSS available, one that can potentially provide NSS support for Tomcat and JBoss via JAAS. It looks like all it requires is a change to the configuration file that we ship. I'm not quite sure how we would go about doing this in an automated fashion, short of pulling in libnss3 as part of Open JDK support. I'm guessing that if we enable it and the nss library is missing it errors our in some ugly manner, but I have not tested it. Is anyone familiar with this code? Would it be acceptable to activate this security module by default and to pull in libnss with Java? Is there some automated way to enable this if NSS is installed?

4 4

javax.xml.stream
by Orion Poplawski 04 Oct '11

04 Oct '11

I'm getting the following trying to build eclipse-ptp 5.0.2: /usr/lib64/eclipse/dropins/sdk/plugins/org.eclipse.pde.build_3.7.0.v20110512-1320/scripts/genericTargets.xml:111: Processing inclusion from feature org.eclipse.ptp.rm.jaxb: Bundle org.eclipse.ptp.rm.jaxb.core_1.0.0.201110041027 failed to resolve.: Missing required plug-in javax.xml.stream_1.0.1. I would have guessed that xml-commons-apis would have provided this (there are items in javax/xml/stream), but there is not an entry for javax.xml.stream in its manifest. File a bug? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion(a)cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com

3 3

Packaging Webapps for Fedora
by Adam Young 03 Oct '11

03 Oct '11

I'm one of the developers working on the next version of Dogtag, the Public Key Infrastructure packages (pki-*) which is, as far as I can tell, the only Java Web app that actually ships in Fedora. PKI is an old project, and it has vestiges of many aspects of Java development that are just done differently today. We are looking to close the gap between where it is and where the Standard lies. As such, we have to figure out how to attack packaging the application. Part of that, for Fedora, is to establish the standard in the first place. Dogtag ships with a utility called pkicreate. This is an application that creates a Tomcat instance in (by default) /var/lib/pki-* and sets the ports, the SELinux policy, the config, etc. While I think it does more than it should, certain aspects of what it does are essential. For example, it handles all of the SELinux configuration for the Tomcat instance. Tomcat ships with SSL disabled, and without an AJP connector to apache. Thus, Tomcat can't serve over port 80 or 443, meaning that they can't be viewed by many people behind firewalls. pkicreate configures mod_proxy_ajp support. It performs the SELinux configuration for the HTTP ports (if they are different from 8080 and 8443 which should be handled by system policy), as well as the AJP port. Russ Alberry, on the Debian Java team, has propsed a deployment utility similar in scope to what pkicreate does, but for the general case: http://dep.debian.net/deps/dep7/ Fedora 17 and later will have JBoss, which has a different set of deployment rules. Geronimo is already part of Fedora, although I have to admit ignorance as far as how it would interact with Tomcat. Resin is a possiblity as well. So we don't want to hardcode the deployment approach to the Tomcat server. But, the Tomcat install should be supported first. For a directory standard, I would say that a Fedora Web app should not have to provide a .war file, but should be able to use the tool to produce one . Many web applications allow for post install customization. THe simplest case is that a Company wants to theme the application with its own images and CSS. If the web application is delivered in a .war file and expects to deploy this way on the Servlet engine, there is no way to customize it. Thus, Russ' approach listed above seems right on. The one thing I would adjust is that deployment as a war file should be an option, but not necessarily the prefereed option. MOst application servers have to unzip war files anyway, and it seems a waste and troublesome to zip up the file only to unzip it. I say war is the exception but not the rule. pkicreate is a Perl application. As such, I don't think it will gain wide acceptance in the Java community. But, it can server as a prototype for A Java based java-deploy-webapp. Here's a short list of functions that I think the deployment tool should handle beyond what is listed in Russ' propsal: 1. Configuring Security Realms 2. Configuring JDBC connections (It would be nice if it configured Postgresql and MySQL for JDBC, too....) 3. Configuring LDAP connections 4. Opening additional ports and providing SELinux configuration for them 5. Creating Symlinks for shared libraries to /usr/share/java and /usr/lib[64]/java 6. Registering generic Global scoped components that can be accessed via JNDI names. It is possible that the workflow for java-deploy-webapp could best be done using either Ant or Maven. However, I would not like to require a .pom or build.xml file as part of the deployment: Web apps should follow the standard, and requiring additional configuration should be supported but not the norm. Perhaps we look for something like /etc/webapp/name/pom.xml and, if it doesn't exist, generate it from a skeleton. Or, we can say that if they provide the pom.xml, then we support deploying this way, otherwise you are on your own.

3 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

java-devel October 2011