commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Gainty <>
Subject RE: Question.
Date Fri, 11 Feb 2011 20:30:14 GMT

i usually stick to the saying "it it aint broke dont fix it .." apparently i am the only person
that thinks time is better spent working on new features
instead of changing old code..
developers who force refactoring of implementation code because someone decided to demote
a String param or return value to Object  (for no reason then excess time on their hands)
produces an end result of endless iterations of re-factoring code (that should NEVER have
to be refactored in the first place) is not my favourite past-time..

that said there are a few immutable exceptions to that rule :

Log4j has pretty much replaced functionality from commons-logging. e.g. defining Levels of
output severe (nothing but worst) vs info (everything and the kitchen sink) and Appenders
(SMTP and FTP as well as File and HTTP Appenders)..ceki thought of everything when he designed
this library
i use log4j almost exclusively ..having come off a situation which used commons-logging i
groaned thru CL which did'nt have the functionality i needed
if any developer here wants to go and replace (the largely untouched commons-logging codebase)
with log4j functionality i say go for it!!!

http-commons is about to get a new facelift when IPV4 addresses run out..which is from my
recollection immediately..we all need to bury the legacy IPv4 addressing schema (it has served
us well for almost 30 years) and go full speed ahead for accommodating IPv6 addresses into
http-commons-(IPv6) library

any thoughts ???
Jogi és Bizalmassági kinyilatkoztatás/Verzicht und Vertraulichkeitanmerkung/Note de déni
et de confidentialité
 Ez az
üzenet bizalmas.  Ha nem ön az akinek szánva volt, akkor kérjük, hogy
jelentse azt nekünk vissza. Semmiféle továbbítása vagy másolatának
készítése nem megengedett.  Ez az üzenet csak ismeret cserét szolgál és
semmiféle jogi alkalmazhatósága sincs.  Mivel az electronikus üzenetek
könnyen megváltoztathatóak, ezért minket semmi felelöség nem terhelhet
ezen üzenet tartalma miatt.

Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten
wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist
unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet
keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen
wir keine Haftung fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire
prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe
quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information
seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les
email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune
responsabilité pour le contenu fourni.

> Subject: Question.
> Date: Fri, 11 Feb 2011 15:09:54 -0500
> From:
> To:
> Hello Common Developers,
> In my department, we have java modules on Unix, some of them uses third
> party tools like:  jasper, some uses hibernate, .... .  Some modules
> uses more than one java third party tool.
> Most of these third party tools uses commons in their code. Now we
> install all of these products in order Unix box and change the class
> path in order to use the third party tool in our modules.
> The question is how to control different releases of commons within the
> same program? How compatible are your new releases with the older ones.?
> Is it safe to substitute always with the latest for all these third
> party tools?
> Please advise.
> Nadia Ayar
> Brokerage Services, Banking and Investment CGI Information Systems &
> Management Consultants Inc. Office Phone Number - (905) 762 2800 X4502.
> 125 Commerce Valley Drive West - 6th Floor Markham, ON L3T 7W4
> CONFIDENTIALITY NOTICE: Proprietary/Confidential Information belonging
> to CGI Group Inc. and its affiliates may be contained in this message.
> If you are not a recipient indicated or intended in this message (or
> responsible for delivery of this message to such person), or you think
> for any reason that this message may have been addressed to you in
> error, you may not use or copy or deliver this message to anyone else.
> In such case, you should destroy this message and are asked to notify
> the sender by reply email. 
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message