Le lun 30/06/2003 � 12:39, Anton Tagunov a �crit : > Hello Nicolas! > > NM> 2. we'd like the build-in backends split from the main jar so we can > NM> made them optional and allow people not to install them if they already > NM> have log4j or a 1.4 jvm. > > Lurker's opinion :) > > I want to say I like your ideas very much. > > war-s are great too, but putting _all_ into the main server classpath, > be it Tomcat or JBoss generally works too; I used to work in this > style.. And if it was a bit more manageable (what your project is > struggling for) it would be just fine. > > I guess problems will come if part of the jars are in WEB-INF/lib > and part on the main classpath, but if you put all on the classpath > it will generally work, I believe. > > And yes, I've heard that you simlink to WEB-INF-s too. > > Now, did I get it right that _despite_ jakarta-logging will be shipped > as a single jar all your stuff _will_ work okay since jakarta-logging > will detect what is available on the classpath and what is not?
Basically if/when we had split the backends we'd had provided a backends symlinks pointing either to log4j, jvm or build-in (with automated priorities). This symlink would have been added to all the logging users classpaths/jer directories So we would have insured there was always a backend on the system, without duplicating classes. The current solution will be the death of log4j since no one will take the pain to put it manually in the classpath (as it would have, if the split had proceeded) Cheers, -- Nicolas Mailhot
signature.asc
Description: Ceci est une partie de message=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
