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
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
$ java JavaConfig --libs-only-L
-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).
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:
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
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
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.
We haven't had a SIG meeting for some time. Agenda:
* aqute-bndlib update (0.0.363 -> 1.43.0)
* Maven 2 vs. 3 status and explanation (if this is needed)
* Java SIG tracker bug status - mostly review bugs
* Open floor
I assume mgoldmann will also have something to say about JBoss AS
progress in Fedora so far and mull might have some updates on
Expect the meeting page to be updated before the meeting.
Stanislav Ochotnicky <sochotnicky(a)redhat.com>
Software Engineer - Base Operating Systems Brno
Red Hat Inc. http://cz.redhat.com
The way that the POMs for the apache ecosystem are structured, it
looks like I'm going to need to package several levels of "parent"
POMs. Something like:
Should each pom be separate, or is there a point at which it makes
sense to group some set of "apache-parent-poms" together? I can go
either way with it, but I want to put these up for review fairly soon,
and didn't want to file a bunch of separate reviews if they should all
just be bundled in a single package.
I had installed
eclipse, java and tomcat by yum and it seems to be ok. Tomcat is
working but eclipse do not load. Running java-version it is there.
Dispite it, I wrote classpath and path manually at profile and
eclipse still is not loading and without any error message. What