[fedora-java] Packaging Webapps for Fedora

Thu Sep 29 08:48:23 UTC 2011

Excerpts from Adam Young's message of Wed Sep 28 16:13:06 +0200 2011:
> 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.

I like your approach. It's great that you are trying to get the
packaging updated instead of working around it.

>
> 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.

I once prepared a tomcat webapp[1] for review and even though it never
got in in the end because I backed off...it should still be a good
starting point. Especially tomcat6 subpackage that installs one simple
XML into Catalina directory and that's all that's needed for tomcat to
recognize new webapp.

I can't really comment on different ports and such, but if you are
right then I guess system policy should be modified either when
installing tomcat itself or globally. I really don't think a second
tomcat instance is the way to go.

> 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/
>
You might want to have a look at one of our SIG meeting logs[2] from
December of last year. We discussed said deployment utility and java
webapps in general there (though we never finished the discussion).

>
> 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.

I'd be careful about saying "Fedora 17 will have JBoss". Marek
Goldmann is trying hard and he's doing a great job, but there's still
a lot of work ahead of us.

> 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.

I believe our initial idea for deployment tool was much more
simple. Maybe we just never understood the real needs. I believe the
discussion could/should be started again. Getting in touch with Russ
would be a good idea too I guess.

> 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.

I don't think an ant/maven approach is viable, though I might be
wrong. Deployment using pom.xml is fine for upstreams, but we'd have
to create our own anyway because we are not really deploying to
upstream servers.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=693646
[2] http://meetbot.fedoraproject.org/fedora-meeting-1/2010-12-08/fedora-meeting-1.2010-12-08-17.07.log.html#l-78

--
Stanislav Ochotnicky <sochotnicky at redhat.com>
Software Engineer - Base Operating Systems Brno

PGP: 7B087241
Red Hat Inc.                               http://cz.redhat.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/java-devel/attachments/20110929/5bf9d8c9/attachment.bin 