> 2011/9/29 Stanislav Ochotnicky: >> Excerpts from Adam Young's message of Wed Sep 28 16:13:06 +0200 2011: > 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. That's true if you want to set some non-default paths, just dropping the war in webapps dir is enough to make tomcat be aware of that and try to start the new context. I think (but im not sure about that) that putting xml files in Catalina directory, in particular when not inside 'localhost', requires a tomcat restart. > 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. Agree with that, but what do you have in mind for packaging webapps, creating a single -tomcat | -jboss | -jetty | -whatever rpm during build for each provided/supported container built from the webapp srpm? >> 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. My knoledge of JBoss is still on v4.3. On that one, i'd say that war/ear IS actually the rule and not the exception, as JBoss does extract the archive in a working directory without custom configuration, and for istance there are other discrepancies (allowed by specification), as getServletContent().getRealPath() returning the actual absolute path in tomcat, and just null in JBoss. Relying on the fact that wars have to be exploded in the context-s directory is also very bad for clustering in my opinion. >> 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. I dont think sysadministrators will likely rely on a script or gui to edit their configuration files. But, a deploy manager could be very useful for the casual user (I mean, anyone like developers or final users of applications written as webapps). That's my hypothetical use-case: 1- in my fedora system i installed tomcat7 and jboss 7 2- i install a mywebapp rpm using yum (just like installing phpmyadmin, but in this case the war is just sitting somewhere, no deploy) 3a- i install a mywebapp-tomcat7 bridge rpm using yum that does most configuration, but not everything or 3b- use a newly written deploy manager to deploy whatever in wherever That could rise a lot of dependant questions: - WEB-INF/lib: the proposal of linking to system jars just wont work so often, as many webapps are written to particular library versions (of commons- or just log4j) - many webapps in the past needed endorsed libs or configuration of bootstrap or jvm keystore - most webapps need a database and come with hibernate, so which backing db engine to configure to be used with hibernate? - how to make the user aware that the user/pass used for database creation have to be changed? and you still have to get somewhere the grant for creating such user - what about specific settings as -Xms or -XX:PermGen for the jvm which could be in conflict among webapps Imho, a fully automated deploy manager is just too complex to implement, and nevertheless, that would probably not let you avoid small manual configurations. What could be really a gift, is an automated tool which does a maximum common set of configurations, or even better, some sort of wizard that in a few steps could let you have running some webapp, that you just had sitting somewhere after installing the relevant packages. -- Guido Grazioli <guido.grazioli@xxxxxxxxx> Via Parri 11 48011 - Alfonsine (RA) Mobile: +39 347 1017202 (10-18) Key FP = 7040 F398 0DED A737 7337 DAE1 12DC A698 5E81 2278 Linked in: http://www.linkedin.com/in/guidograzioli -- java-devel mailing list java-devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/java-devel
