[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Java webapps and configuration files



Matthew Johnson <mjj29@debian.org> writes:
> On Sun Aug 22 17:41, Russ Allbery wrote:
>> Matthew Johnson <mjj29@debian.org> writes:

>>> I'm not sure that you need to ship them as conffiles though - lots of
>>> package have this sort of thing in /usr/share/doc/$package/examples
>>> (the jsp) - so you would build a default war from those (on install?)
>>> and then users can build their own from the examples if they wanted.

>> Packages aren't allowed to assume that /usr/share/doc exists, so if we
>> put them there, we wouldn't be able to build a WAR file including them
>> on install.  Plus, in general, I suspect we're going to want conffile
>> semantics for things like this, since some users may have simple needs
>> that are satisfied by (at least some of) the default sample files and
>> will want to get updates of them applied automatically.

> They aren't? Fair enough, I'd missed that.

Yeah, Policy 12.3.  I think a lot of people miss that.

    Packages must not require the existence of any files in
    /usr/share/doc/ in order to function. Any files that are referenced by
    programs but are also useful as stand alone documentation should be
    installed under /usr/share/package/ with symbolic links from
    /usr/share/doc/package.

> Perhaps somewhere they can assume, symlinked from doc?

That would work if they really seem like documentation, but I feel like
these really are configuration files.  But, taking a step back since I
want this to be a more general discussion, we should document both and let
the package maintainer decide whether they're configuration files or
documentation, since we will, in the long run, certainly encounter both.

> The war-file builder could take the defaults from wherever if they
> aren't overridden?  That would give you the unchanged files semantics,
> and I don't think a 3-way merge, should we every implement that, will be
> very helpful here

Well, for the login.jsp page for example, if the names of the Java classes
ever changed, a three-way merge would fix the user's login page fairly
cleanly.  But that's probably an unlikely situation.

I suspect that web.xml is often going to need to be a conffile, and there
will sometimes be other files inside the webapp that will need to be
conffiles.  I think that JSPs are rarely going to want to be conffiles,
but in some cases the package maintainer may want to do that.

> Yeah, that's not really something I'd expect to see in etc.

Where would you have the user put their customized login.jsp page to be
picked up by the webapp?

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>


Reply to: