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@xxxxxxxxxx> Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com
Attachment:
signature.asc
Description: PGP signature
-- java-devel mailing list java-devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/java-devel
