commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Mailhot <Nicolas.Mail...@laPoste.net>
Subject Re: Logging packaging questions
Date Mon, 16 Jun 2003 19:57:05 GMT
Le lun 16/06/2003 à 21:17, David Graham a écrit :
> I don't work on commons-logging so I won't speak to satisfying your request 
> but I am curious about why you need this behavior.

Because that's how it's done on linux systems:).

> I would *never* allow 
> all of my apps to share jars between them and upgrade them all at the same 
> time.

Well, unsynched jars only means you have x versions of the same jar to
track instead of only one. Which means x more work if you're serious (ie
you do not consider because you don't seem to hit the same bug in other
apps means their jars are more sane than the one you've just fixed).

Proper modularity is critical to get a system stable and secure - it
means one can quickly roll security fixes because there is a single node
to fix (and rollback rotten versions) ; also all components are properly
tested because all apps exercise the same version. The -logging problem
for example was found in tomcat4 but all logging users will have the fix
once we've done it.

This is actually very similar to software coding in a bigger context. No
one would advocate copying the same snippet of code over and over again
to avoid being hit everywhere by a single change - the correct practise
is to modularise code because the problems a single shared error could
cause are less than the bitrot caused by code duplication.

The bonus being - we save on disk space/memory.

> The amount of testing that would require is simply unreasonable not 
> to mention the fact that all apps aren't on the same development/deployment 
> cycle.

Just because it's more spread out does not mean duplicate jar testing is
less expensive. In fact it's more so because one keeps retesting the
same software all over again, instead of getting *one* version right.

> IMO, sharing jars in this way is asking for trouble.

C linux apps history proves otherwise. And there is no reason not to
apply the same methods to java apps.

The experience of the project to this day is initial sharing does bring
to light lots of problems. But once they are fixed the system is more
solid than before the sharing. All apps get their critical fixes *and*
the fixes for all the problems not critical for them but critical for
some other user of the same jar.

Regards,

-- 
Nicolas Mailhot

Mime
View raw message