[fedora-java] Packaging Webapps for Fedora

[Adam Young]

On 09/29/2011 07:06 AM, Guido Grazioli wrote:
>> 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.

Restarting Tomcat for initial deploy is probably OK.  For hot deploy 
scenarios, people  will likely want JBoss, and we shouldn't be trying to 
reimplement that here.  Lets focus on the simple cases first.


>
>
>> 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?
No.  I don't think this should be done at RPM package time.  I see three 
supported scenarios

1.  RPM creates a war file and that is what the tool  deploys as is.
2.  RPM create an exploded war directory.  Tool  merges in  config files 
from /etc/tomcat6/<webapp> with the code from /usr/share/java/webapps  
and creates a war file and deploys it
3. Same as 2 but code is deployed in exploded form.


For 2, copies of dependancy lbraries are put into WEB-INF/lib,  for 3, 
it is done with symlinks.




>
>
>>> 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.
Agreed.  We should support both exploded and packaged deployments.


>
>>> 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).
A good sysadmin should be using something like puppet to ensure that all 
servers are kept in sync,  and so on.  Automated deployments should 
provide a reasonable set of defaults for a web application.It may be 
that we want to "wizardize it"  for some choices, like "you have both 
postgres and mysql installed, which do you want to use"


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

In exploded view do the linking,  for a war view, do a copy.  This is 
for Fedora applications, so they should be deploying with the Fedora 
versions of standard libraries.  A web app that wants to deploy with 
F17   and uses log4j needs to work with the version deployed with F17 as 
well.  We can provide a way to override this for people that want to use 
the tool for non-standard library versions, but that is not the goal, as 
I see it.

> - 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.
I don't see it being fully automated.  More of a guide-you-through-it 
with-reasonable-defaults  tool.  A user should be able to run in in 
unattend mode by providing certain command line switches...or, 
conversely,  if we wnat the default to be  run it unattended, provide a 
switch --interactive and prompt them.  If run in unattended mode, and 
one of the values is invalid, the whole thing should fail as a unit.

We should also track the files we modify, provide copies of the 
originals, and clean up on uninstall of the webapp.

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


Note that whey I suggested using maven, I did not mean that we should 
use the same pom as is used to build the application.  What would make 
more sense is to provide a fragment of a pom used just for deployment.  
I'd see it something like this:


in /etc/jwebapp/myproject.pom  (hey. why not!  seriously, though, 
where?  Should not be /etc/tomcat6...yes, I did this in JSON, to make it 
easier to read )

{
   {common:
      {format:war},  # as opposed to exploded
      {libs:[commons-codec,commons-logging]},
      {realm: simple},
   {tomcat6: ... }
   {jbossas5: ... }
}
    

and then

/usr/bin/jwebapp  myproject  --deploy  --server  tomcat6

Or something.  Probably should keep  these .poms in 
/usr/share/java/webapps,  but again allow users to customize them.