LRU-Indentity-HashMap

2004-10-27 Thread Ceki Gülcü
Hello all,
In addressing bug #6229 [1], it transpired that we needed a bounded
hash map using LRU heuristics and identity to compute hashmap and
object references for equality. Basically, it would be a HashMap
merging the qualities of a LRUMap [2] and those of IdentityHashMap [3,
4, 5].
This HashMap will serve as a cache of previously parsed logging
messages of type java.lang.String. String has rather slow equals and
hash methods, hence the need for an IdentityMap. We need to keep the
memory footprint of the cache limited, hence the requirement for the
LRU heuristics.
It's a little 2 or 3 day project. If you are interested, please let me
know.
[1] http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16229
[2] 
http://jakarta.apache.org/commons/collections/apidocs-COLLECTIONS_3_1/org/apache/commons/collections/map/LRUMap.html
[3] http://java.sun.com/j2se/1.4.2/docs/api/java/util/IdentityHashMap.html
[4] 
http://ws.apache.org/axis/java/apiDocs/org/apache/axis/utils/IdentityHashMap.html
[5] 
http://jakarta.apache.org/commons/collections/apidocs-COLLECTIONS_3_1/org/apache/commons/collections/map/IdentityMap.html

ps: Please reply to [EMAIL PROTECTED]
--
Ceki Gülcü
 For log4j documentation consider The complete log4j manual
 http://www.qos.ch/shop/products/eclm/  


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Jakarta: Confederation or Single Project?

2003-12-20 Thread Ceki Gülcü


Log4j is not leaving. It is simply moving to a new room in the house,
a room with a different label but still located within the same house.
As any house, this house offers protection and comfort to its
inhabitants. It is a place where developers can unleash their creative
powers onto the world. But this house is unique in its degree of openness
and tolerance. Apache is a great place to be regardless of the room
you chose.
As for log4j, its developers will continue to be involved with
Jakarta. Many of us use Jakarta products in our daily work. Moreover,
without the software contained in Jakarta, there wouldn't be much use
for log4j.
So there are no goodbyes to be said, we are just next door. No need to
put on shoes, you can hang on to your slippers. Our door is open, you
don't have to knock when you come in.
At 07:23 AM 12/20/2003 -0500, Geir Magnusson Jr. wrote:

On Dec 19, 2003, at 3:33 PM, Costin Manolache wrote:

Ted Husted :


[SNIP]

I agreed w/ every word from Costin.

And look what's happening with logging: Now that it's a TLP, they are 
bringing-in the various Log4J compatibles. Now, there can be one Apache 
logging project serving every platform. That's community-building!

Is logkit included in the logging TLP ? What about commons-logging ?

I agree with you that the logging TLP does define a community ( just 
like  jakarta or httpd ). It's a separate PMC bringing togheter different 
codebases and people.

It remains to be seen if log4j as a TLP will be better than log4j as part 
of jakarta. There are plenty of TLPs - like apache-commons - that
don't seem to be much better than sub-projects like jakarta-commons.
Agreed.  JC is a vibrant sub-project with ties to may Jakarta 
sub-projects.  I think that important and valuable.  I think log4j will do 
fine, and they can always come back.  It's not clear what kind of synergy 
the log4* projects will bring together, but will be interesting to watch.

I had such mixed emotions about log4j leaving, as I think it's going to 
take a bit of our community away.  On the other hand, I support the 
freedom of the log4j community to choose it's own path, and that wins out 
with me.

geir

--
Geir Magnusson Jr   203-247-1713(m)
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Ceki Gülcü
 For log4j documentation consider The complete log4j manual
 ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: TRACE level [WAS] Jakarta: Confederation or Single Project?

2003-12-20 Thread Ceki Gülcü
At 08:31 AM 12/20/2003 -0500, Geir Magnusson Jr. wrote:

public_pestering type=obligatory
Can we have TRACE as a supported level?
/public_pestering
Subsequent to the demand for the TRACE level expressed by a number of user, 
there is every reason to believe that a vote will be held on this topic 
before log4j 1.3 is released. However, there is still time as log4j 1.3 
will not be released in the immediate future.

--
Ceki Gülcü
 For log4j documentation consider The complete log4j manual
 ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: TRACE level [WAS] Jakarta: Confederation or Single Project?

2003-12-20 Thread Ceki Gülcü
At 08:42 AM 12/20/2003 -0500, Geir Magnusson Jr. wrote:

On Dec 20, 2003, at 8:40 AM, Ceki Gülcü wrote:
Subsequent to the demand for the TRACE level expressed by a number of 
user, there is every reason to believe that a vote will be held on this 
topic before log4j 1.3 is released. However, there is still time as log4j 
1.3 will not be released in the immediate future.
Good.  that gives me time to continue badgering in public. See :

http://www.theserverside.com/home/thread.jsp?thread_id=22944

I hope you are taking this with the good nature in which it is intended.
No worries. Although my reply was somewhat dry, the good intentions of your 
comments were totally clear. I definitely have to get myself a sense of 
humor. Unfortunately, you can't buy nor open source humor.

geir

--
Geir Magnusson Jr   203-247-1713(m)
[EMAIL PROTECTED]
--
Ceki Gülcü
 For log4j documentation consider The complete log4j manual
 ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


[ANNOUNCEMENT] Apache Logging Services project

2003-12-18 Thread Ceki Gülcü
Good morning to all,

The log4j developers are pleased to announce that the Board of
Directors of the Apache Software Foundation unanimously passed a
resolution for the creation of the Apache Logging Services project. A
copy of the resolution can be found at:
http://nagoya.apache.org/wiki/apachewiki.cgi?LoggingApacheOrg/BoardResoluion

The Logging Services project is intended to provide cross-language
logging services for purposes of application debugging and
auditing. The discussions leading to the submission of this resolution
can be found at:
 http://marc.theaimsgroup.com/?t=10711552621r=1w=2

We should also mention that thanks to the relentless efforts of many
developers and in particular those of Scott Deboy, we currently have
inter-operability between the following projects:
 * Log4Cxx (c++)
 * Log4CPlus
 * Log4j
 * Log4Net
 * Log4Perl
 * Log4PHP
 * JDK1.4's util.logging framework
There is still much work ahead bringing in the various projects to
work together within the Logging Services Project. The process is
likely to take a little while. In the mean time, we will continue to
do what we like best, that is developing open source software.
Happy holidays to all,

--
Ceki Gülcü
 For log4j documentation consider The complete log4j manual
 ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Only 17 days left to register at ApacheCon!

2003-10-30 Thread Ceki Gülcü
Greetings to all,

I just wanted to bring your attention to the fact that there
are only 17 days left for registering at ApacheCon US/2003!
--
Ceki Gülcü
 For log4j documentation consider The complete log4j manual
 ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
 import org.apache.Facetime;
 ApacheCon US 2003, 18-21 November http://apachecon.com/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


JSP editor for Eclipse

2003-10-27 Thread Ceki Gülcü
Hello all,

I am looking for a JSP editor for Eclipse. Any recommendations on this front?

--
Ceki Gülcü
 For log4j documentation consider The complete log4j manual
 ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
 import org.apache.Facetime;
 ApacheCon US 2003, 18-21 November http://apachecon.com/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


RE: JSP editor for Eclipse

2003-10-27 Thread Ceki Gülcü
Thanks Scot.

I'm mainly interested in syntax highlighting and also tag completion, e.g. 
adding /p after a p. The lomboz editor does not seem to do tag completion.

At 07:54 AM 10/27/2003 -0800, Scot Hale wrote:
I am using the Lomboz plugin, which is much more than a jsp editor, but it
syntax colors nicely.
-Original Message-
From: Ceki Gülcü [mailto:[EMAIL PROTECTED]
Sent: Monday, October 27, 2003 2:46 AM
To: [EMAIL PROTECTED]
Subject: JSP editor for Eclipse
Hello all,

I am looking for a JSP editor for Eclipse. Any recommendations on this
front?
--
Ceki Gülcü
  For log4j documentation consider The complete log4j manual
  ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
  import org.apache.Facetime;
  ApacheCon US 2003, 18-21 November http://apachecon.com/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Ceki Gülcü
 For log4j documentation consider The complete log4j manual
 ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
 import org.apache.Facetime;
 ApacheCon US 2003, 18-21 November http://apachecon.com/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Fwd: Reminder: Hyper-Early Bird Registration Ends Soon

2003-09-26 Thread Ceki Gülcü
FYI

Date: Fri, 26 Sep 2003 09:35:38 -0700 (PDT)
From: Sally Khudairi [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Subject: Reminder: Hyper-Early Bird Registration Ends Soon
 + + ONLY 4 DAYS LEFT + +

Hyper-Early Bird Registration for ApacheCon 2003 is
available until 23.59ET on 30 September.
By registering now, you can save up to US$400!

   ApacheCon US 2003
   16-19 November 2003
   Alexis Park Resort
   Las Vegas, Nevada, US
More than 60 sessions highlight core and
next-generation Apache server tools, offering a wide
range of beginner, intermediate and advanced sessions.
Learn firsthand the latest developments in Apache, the
world's most popular Web server software, as well as
key open source projects, including PHP, Perl, XML,
Java, MySQL, and WebDAV. ApacheCon 2003 is going to be
a great event with a three-day vendor expo, social
activities, BOFs and more.  We want you to be a part
of it!
   Hyper-Early bird registration fee: US$499
   After 30 September: US$599
   After 20 October: US$799
   After 16 November: US$899
Register today at http://www.apachecon.com/
We look forward to seeing you there!
- Sally Khudairi
--
Ceki Gülcü
 For log4j documentation consider The complete log4j manual
 ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
 import org.apache.Facetime;
 ApacheCon US 2003, 18-21 November http://apachecon.com/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Publicizing ApacheCon 2003

2003-09-04 Thread Ceki Gülcü
If I am not mistakem, early-bird registration seems to be already over...

Anyway, I added a link at the top of the jakarta sidebar menu. I am 
confident people will find things to improve but you've got to start somewhere.

This is CVS. We can revert if need be.

At 07:41 AM 9/4/2003 -0500, Glenn Nielsen wrote:
+1 But wait until the sessions are available at www.apachecon.com

Ceki Gülcü wrote:
Hello everyone,
Apachecon 2003 will take place in Las Vegas, Nevada, USA, 16-19
November 2003.
For this event to be the success that it deserves to have, we need to
make an effort to publicize it as much as possible.
I have created a series of icons that one can use to link to
http://www.ApacheCon.com. The icons are available at
  http://www.apache.org/~ceki/ac2003/
We should at least add a salient image on the sidebar of the jakarta
pages.
Comments?
--
Ceki Gülcü
 For log4j documentation consider The complete log4j manual
 ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
 See you in November at ApacheCon US 2003 in Las Vegas.
 http://apachecon.com/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Publicizing ApacheCon 2003

2003-09-04 Thread Ceki Gülcü
My bad!

At 03:03 PM 9/4/2003 -0400, you wrote:
Actually, as registration isn't open yet, the early-bird is quite a farce.

-Brian

On Thursday, September 4, 2003, at 02:31 PM, Andrew C. Oliver wrote:

Christ, they just got it together.  While I'm covered, folks were for months
asking Are we having an apachecon and then it was barely advertised with
no sessions scheduled yet and early bird is already over?  If I were any joe
off the street I'd probably want to at least have some vague idea what would
be covered before registering even if I wanted to register as early as
possible.
On 9/4/03 12:13 PM, Ceki Gülcü [EMAIL PROTECTED] wrote:

If I am not mistakem, early-bird registration seems to be already over...

Anyway, I added a link at the top of the jakarta sidebar menu. I am
confident people will find things to improve but you've got to start
somewhere.
This is CVS. We can revert if need be.

At 07:41 AM 9/4/2003 -0500, Glenn Nielsen wrote:
+1 But wait until the sessions are available at www.apachecon.com

Ceki Gülcü wrote:
Hello everyone,
Apachecon 2003 will take place in Las Vegas, Nevada, USA, 16-19
November 2003.
For this event to be the success that it deserves to have, we need to
make an effort to publicize it as much as possible.
I have created a series of icons that one can use to link to
http://www.ApacheCon.com. The icons are available at
  http://www.apache.org/~ceki/ac2003/
We should at least add a salient image on the sidebar of the jakarta
pages.
Comments?
--
Ceki Gülcü
 For log4j documentation consider The complete log4j manual
 ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
 See you in November at ApacheCon US 2003 in Las Vegas.
 http://apachecon.com/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Andrew C. Oliver
http://www.superlinksoftware.com/poi.jsp
Custom enhancements and Commercial Implementation for Jakarta POI
http://jakarta.apache.org/poi
For Java and Excel, Got POI?
The views expressed in this email are those of the author and are almost
definitely not shared by the Apache Software Foundation, its board or its
general membership.  In fact they probably most definitively disagree with
everything espoused in the above email.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Ceki Gülcü
 For log4j documentation consider The complete log4j manual
 ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
 See you in November at ApacheCon US 2003 in Las Vegas.
 http://apachecon.com/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


The Rules of Open-Source Programming

2003-06-06 Thread Ceki Gülcü
Here are some OSP rules that might be of interest:

  http://www.advogato.org/article/395.html

Enjoy!

--
Ceki  For log4j documentation consider The complete log4j manual
  ISBN: 2970036908  http://www.qos.ch/shop/products/clm_t.jsp 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Sun

2003-05-28 Thread Ceki Gülcü
At 08:47 AM 5/28/2003 +0100, you wrote:
On 28/5/03 0:26 Andrew C. Oliver [EMAIL PROTECTED] wrote:

 Good: http://www.theserverside.com/home/thread.jsp?thread_id=19500

Hm...

 Evil:
 http://www.shiftat.com/blog/page/werner/20030527#sun_reaffirms_no_jboss_at
Indeed... Mark Fleury _is_ evil.
He has a character but evil? A bit harsh no?

   Pier
--
Ceki  For log4j documentation consider The complete log4j manual
  ISBN: 2970036908  http://www.qos.ch/shop/products/clm_t.jsp 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Sun

2003-05-28 Thread Ceki Gülcü
At 10:08 AM 5/28/2003 +0200, you wrote:
On 28/05/2003 9:47 Pier Fumagalli wrote:

Going back and looking at the past 5 years, actually, I think that in this
case, the guy from Sun actually has a point (Rudy? Who the hell is he?).
Oddly enough in the J2EE/JBoss saga, I don't see Sun as being the bad guys
(but ok, some of us and Mark go back A LONG time)...
I concur that. The JBossGroup is playing a very tricky game, and some of 
what they do will reflect bad upon the entire Open Source community. Rest 
assured that Werner knows about these tricks since he was involved with 
JBoss in Europe from the beginning. I'm not a Fleury fan, neither, and his 
latest acts (the whitepapers, trying to lure committers into a commercial 
liaison with JBG) have confirmed my feelings.
Don't you think JBoss' huge success has something to do with Sun's
animosity? Every developer I know who has a say on the platform uses
JBoss: better product, better documentation, better support, lower
price.
Do you think Sun Microsystems cares one bit about the well being of
Open Source? The fact that Sun is actively trying to scuttle a
successful OS project, JBoss in this case, is very disturbing.
/Steven
--
Ceki  For log4j documentation consider The complete log4j manual
  ISBN: 2970036908  http://www.qos.ch/shop/products/clm_t.jsp 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: PMC Nomination

2003-02-19 Thread Ceki Gülcü
At 15:41 19.02.2003 -0500, you wrote:

Geir Magnusson Jr. wrote:

Shouldn't it be that a committer has been around for a reasonable amount 
of time?  How else would they be a committer?

From the perspective of other ASF projects (e.g., HTTPD), Jakarta gives 
out committer-ship like candy.  With HTTPD, a track record of 
approximately six months of sustained patches is required to become a 
committer.

By contrast HTTPD, by Jakarta standards, gives out PMC membership and ASF 
membership like candy.

I want to strike a happy balance.  I don't necessarily want to slow down 
the rate at which people become committers.  But I would like to see 
significantly more Jakarta committers become PMC and ASF members.

+1

By the way, when are the next membership nominations?


- Sam Ruby


--
Ceki 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [PMC VOTE] PMC Nominations

2003-02-19 Thread Ceki Gülcü
At 19:26 13.02.2003 -0500, you wrote:

Charles Burdick wrote:

Selection criteria aside, I nominate Morgan for the PMC.
Now that I think of it, let me just skim through the
Jakarta-Announcements archive from various points last year.
 - Danny Angus
 - Peter Carlson
 - Morgan Delagrange
 - Pier Fumagalli
 - Ceki Gülcü
 - Dmitri Plotnikov
 - Phillip Rhodes
To add to the list, I'd like to nominate these active committers:
 - James Strachan
 - Jason van Zyl
 - Ted Husted
 - Rod Waldhoff


+1

I'd like to add Mark Womack to the list of candidates.


- Sam Ruby


--
Ceki 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [PMC VOTE] PMC Nominations

2003-02-19 Thread Ceki Gülcü

Hi Robert,

I think Mark's nomination follows the sprit set by Sam's initial note.
http://marc.theaimsgroup.com/?l=jakarta-generalm=104275438831116w=2

As such, I don't see a need for a separate vote.


At 22:16 19.02.2003 +, you wrote:

hi ceki

wouldn't it be less confusing to have a separate vote for mark?

while i'm thinking about it, is general or pmc the right place for votes 
of this kind?

- robert

On Wednesday, February 19, 2003, at 09:15 PM, Ceki Gülcü wrote:

At 19:26 13.02.2003 -0500, you wrote:

Charles Burdick wrote:

Selection criteria aside, I nominate Morgan for the PMC.
Now that I think of it, let me just skim through the
Jakarta-Announcements archive from various points last year.
 - Danny Angus
 - Peter Carlson
 - Morgan Delagrange
 - Pier Fumagalli
 - Ceki Gülcü
 - Dmitri Plotnikov
 - Phillip Rhodes
To add to the list, I'd like to nominate these active committers:
 - James Strachan
 - Jason van Zyl
 - Ted Husted
 - Rod Waldhoff


+1

I'd like to add Mark Womack to the list of candidates.


- Sam Ruby


--
Ceki

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



--
Ceki 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Licensing again.

2003-02-12 Thread Ceki Gülcü

I echo Andrew's reservations. The reasons behind the restriction of
LGPLed imports are unclear and apparently undocumented. Such a crucial
matter deserves to be properly documented. If the restriction cannot
be justified, then it should be lifted.

I urge all Apache members and committers to carefully follow licensing
related discussions. The matter is too important to be blindly
deferred to the wisdom of the board. Think a little on yourself. Read
the BSD license. Understand its sprit. Read the Apache license. See
how much or how little it differs.

At 10:30 09.02.2003 -0500, Andrew C. Oliver wrote:

I'd like to state my preference that this ASF policy be changed in the 
near future.  I prefer to be able to collaborate freely with other 
opensource developers.  I find this policy needlessly obstructs this 
abillity.  I understand that IBM and Sun (referring to Sam's earlier 
explanation) have a compelling coporate interest in being able to create 
commercial forks of Apache's products, however introducting LGPL 
dependencies does not prevent this, it only prevents them from forking 
that dependency.  If that were a problem, them having to create a new 
proprietary edition of that dependency is prefferable in my opinion to the 
Opensource developers having an arbitrary barrier to collaboration.

-Andy



This following is to the best of my understanding, and as simply as I 
know how to state it:
There is no reason that ibiblio cannot distribute L/GPL binaries, subject 
to the conditions of those licenses.  There is no reason why such 
binaries can not be placed there by ASF personnel.  Depending on the 
license, similar statements can be made about other binaries from various 
sources.
It is ASF policy at this time that the runtime of any ASF codebase may 
not involve the Java import of any L/GPL code.  This is to be interpreted 
as the transitive closure of imports: if A (ASF) imports B (non ASF) 
which imports C (L/GPL), then A is in violation of this policy.  Compile 
time only dependencies (like running Checkstyle on POI) are not an issue, 
though I would encourage everybody to make such dependencies purely optional.
The reasons behind this policy involve on an appreciation of the needs of 
people who wish to include ASF code in proprietary and commercial 
products.  Being able to serve such a wide audience is a core value of 
the ASF.  This advice is based on Roy and others having sought after and 
obtained legal advice and council.  I am aware that Brian and others have 
been working to resolve this for some time, but I have no expectation 
that this will be resolved soon.
I hope this makes things clearer.  I am copying board@apache in order to 
solicit clarifications and/or corrections.  If you do not hear of any 
such changes in the next few days, please treat this as official ASF policy.
- Sam Ruby

--
Ceki 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Licensing again.

2003-02-12 Thread Ceki Gülcü
At 07:21 12.02.2003 -0500, Sam Ruby wrote:


LGPL has special rules for 'link'.  What exactly is the concept of a 
'link' in Java?  If A imports B and A and B are not in the same Java 
package (but perhaps share some similar names in the first three 
qualifiers) are they in the same 'library' or not?

Indeed, reading the LGPL does not give a clear answer. Thank you for 
pointing out the heart of the issue.

Java has been around for some time, and you would think that this would 
some clarification of how these concepts map to Java would have been 
provided.  Can we read something into the fact that it has not?

If you chose to. However, if would be better not to read anything into that 
fact.

More importantly would you be willing to risk the value of your reputation 
and some important software assets on the chance that a jury of 12 people 
would agree with what we decided to assign to the meaning of terms used in 
the LGPL license?

It depends on the formulation of the license. In the case of LGPL, I would 
certainly not want to take that risk.

It is not up to the ASF to define what the FSF means when they say 'link' 
and 'library' in the context on Java.

No, it is not up to the ASF. However, has the ASF attempted to clarify the 
matter with the FSF? Why not ask the FSF if importing java classes is 
considered as derivative work or simply as work that uses the library?

In the absence of a clear response from the FSF, there is no doubt that it 
is safer to shy away from LGPLed code.

I urge all Apache members and committers to carefully follow licensing
related discussions. The matter is too important to be blindly
deferred to the wisdom of the board. Think a little on yourself. Read
the BSD license. Understand its sprit. Read the Apache license. See
how much or how little it differs.


I would encourage general discussion of this on [EMAIL PROTECTED] This 
topic has a much wider applicability than Jakarta.

Sure.


- Sam Ruby


--
Ceki 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Logging strategy

2003-01-29 Thread Ceki Gülcü
At 11:21 29.01.2003 +0100, Dani Estermann wrote:

Has jakarta got a strategy/guideline/regulation that recommends a certain 
logging api to be used by jakarta projects? Are existing and future 
jakarta projects allowed to choose between log4j, LogKit, commons-logging 
or even JDK1.4-Logging?

We are currently choosing a logging api and implementation to be used 
in  our business projects. While I favor the power of the log4j 
implementation, I ask myself if it would be wise to use a -- maybe more 
future-proof -- thin bridge like commons-logging on top.

I believe log4j is here to stay. Its user base is large and
growing. As time passes, more people will gravitate to it as it keeps
improving. We have enough cool features in pipe to keep us busy for
the foreseeable future. Simile, the future is bright and open!


Daniel


--
Ceki



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




[OT] Pointedly Extreme Programming

2003-01-09 Thread Ceki Gülcü

This one surely will become a classic:

http://www.unitedmedia.com/comics/dilbert/archive/dilbert-20030109.html


--
Ceki



--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: Short Apache licence for source files

2002-12-09 Thread Ceki Gülcü
At 20:27 07.12.2002 +0100, you wrote:

Pier Fumagalli wrote:


You're free to file your complaint to the appropriate department dealing
with those kinds of issues: mailto:[EMAIL PROTECTED]


Naaah. There's a difference between making a remark here when the 
opportunity is there, and starting another 'feeding the trolls' thread 
over at [EMAIL PROTECTED]

I now see that my remark has been duly noted, and I can only hope that it 
somehow penetrates the firewall between us and The Members.

I think the tradition of meritocracy is deeply rooted in our
collective consciousness; I mean that of Apache. If you knock on the
door of [EMAIL PROTECTED], I am sure you will be allowed in. Things
do not necessarily become easier as a member, one still has to work on
listening, understanding and persuasion, exactly the same way a
a committed committer would.

Send an email to [EMAIL PROTECTED] and see how you are
received. Note the CC: to licensing@.



/Steven
--
Steven Noelshttp://outerthought.org/


--
Ceki



--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: Short Apache licence for source files

2002-12-09 Thread Ceki Gülcü
At 12:23 09.12.2002 +0100, Steven Noels wrote:

Ceki Gülcü wrote:

- things being 'easier' when being a member: of course not, and I hope 
that wasn't the impression that I gave

The message I was trying to get across was that the firewall
a.k.a. barrier between members and committers exists mostly in
people's minds. Membership is not much more than a recognition of
one's work plus a stamp of approval for being usually reasonable.
Think of membership as even more positive karma in slashdot. From the
Foundations perspective membership also entails responsibilities and
obligations but that's a different topic.



/Steven


--
Ceki



--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: Short Apache licence for source files

2002-12-09 Thread Ceki Gülcü
At 07:40 09.12.2002 -0500, James Taylor wrote:

 - things being 'easier' when being a member: of course not, and I hope
 that wasn't the impression that I gave

 The message I was trying to get across was that the firewall
 a.k.a. barrier between members and committers exists mostly in
 people's minds. Membership is not much more than a recognition of
 one's work plus a stamp of approval for being usually reasonable.
 Think of membership as even more positive karma in slashdot. From the
 Foundations perspective membership also entails responsibilities and
 obligations but that's a different topic.

It is a real barrier in that things seem less opaque for members. You
can tell people that nothing important happens on the members only
lists, but as long as there _are_ members only lists and such, the
firewall will always be percieved.


Many things remain opaque for members because new members do not
suddenly become omniscient. The phenomena of community legends exists
within Apache as within any community with some history. What sets
Apache apart from other communities is its built in open and tolerant
nature.  Openness is a hard term to define. IMO, the ability to speak
up and argue on almost any matter without fear of retribution makes
Apache open.

You will not find a single member claiming that important business is
conducted on the members list. The argument of members only mailing
lists preventing committers from gaining access to important
information does not hold water unless one assumes that all ASF
members are irredeemable liars united in a conspiracy against the poor
committers.

Some say that perception is everything. If perception is everything,
then reason and truth do not matter.  As far as I am concerned, reason
and truth are everything with perception a distant contender. After
all, we all perceive the earth to be flat which does not make the
earth any less spherical.

What is great about Apache is that a good argument and some
perseverance will get you a long way. That is a fact.  Status matters
but less than one would imagine. My disappointment with Apache was
that occasionally you get a very persistent person who convincingly
promotes bad ideas. Although some may see that and not agree, they
eventually throw in the towel. It then takes the community months or
even years to realize that the idea was bad. Of course, the problem
does stem from the open nature of the ASF but rather from the
imperfections of *any* conceivable system. The bottom line is that we
should not mistake the failings of the system with our own PGL
syndrome (paranoia, greed and laziness).


-- jt, observing not complaining.


--
Ceki, expounding not accusing.




--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




RE: Short Apache licence for source files

2002-12-05 Thread Ceki Gülcü
At 16:14 04.12.2002 -0800, Craig R. McClanahan wrote:


In the mean time, I believe all Apache projects should treat the Board
member comments quoted above and elsewhere in this thread (and taken out
of much larger discussions) as authoritative direction to ASF committers
that we should use the long form of the ASF 1.1 license in every source
file checked in to Apache CV repositories.

It doesn't matter whether it's legally required (to get around the this
software interpretation) or not.  It matters that the ASF Board
(representing the foudnation, which is the owner of all this code) told us
to do it that way.  That's all the reason any of us should need.


I thought that we were also supposed and even encouraged to think for
ourselves. No one has suggested to defy the board. I resent the shut-
-up-and-do-as-you-are-told attitude which does not characterize you,
the ASF, nor anyone on the board. What is going on here?


Craig McClanahan


--
Ceki

TCP implementations will follow a general principle of robustness: be
conservative in what you do, be liberal in what you accept from
others. -- Jon Postel, RFC 793



--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: Short Apache licence for source files

2002-12-05 Thread Ceki Gülcü
At 05:52 05.12.2002 -0500, Sam Ruby wrote:

Ceki Gülcü wrote:

Would a shut-up-and-think-for-yourself be any better?  It seems to me that 
you are seeking an explicit sanction for the practice of using the current 
license by reference.

Yes, shut-up-and-think-for-yourself would be better assuming it came
with at least a hint for the reasons behind the policy. Until very
recently, I could not find any explanation for the reasons behind the
policy beyond *someone* on the board said so, now please go
away. Moreover, when we submitted this question to the board the
answer was far from clear-cut, although that may be due to a
misunderstanding on my part.


The ASF is very much centered around an open and pragmatic license.  If 
you want to weaken this a bit in the name of saving a few bytes, the ASF 
is not going to falter and fold.

I never expected the ASF to falter and fold. However, I do expect the
ASF to act reasonably which implies that it can explain/document its
decisions. Is that too much to ask for?

By the way, I am not seeking a sanction. I am trying to understand.


At the moment, this may be the closest thing to a sanction you may 
get.  If a better one becomes available, I'll be sure to forward it on.

You know where to reach me.


Peace.


Acked and mirrored.


- Sam Ruby


--
Ceki



--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: Short Apache licence for source files

2002-12-04 Thread Ceki Gülcü

Given that for works published after March 1, 1989 it is not even
necessary to place a copyright notice to benefit from copyright law
protection, I do not see why the long form is absolutely
necessary. Moreover, the next version of the Apache Software License
will specifically allow the short form. It may be slightly better to
include the whole license in certain obscure circumstances but that
does mean that the reference to the license (a.k.a. the short form) is
useless and that it should be disallowed.

Here is what Roy Fielding had to say on the subject. I am quoting
without explicit permission hoping that he will not mind. :-(

quote

   and inclusion by reference isn't suddenly becoming official with the
   2.0 licence; until we hear counsel that says its safe, we most likely
   won't permit it regardless of the size of the licence text.

  WTF?  Of course it is safe, and we've already had several lawyers
  review it, not to mention ample evidence from the MPL and GPL that
  other lawyers believe it is safe with the proper reference text.  The
  proposed 2.0 license text was specifically written to support
  inclusion by reference.

  The problem with the 1.1 license is that it lacked a way to define the
  scope of what was covered beyond this file.  As such, the board has
  not approved its use by reference for our own products.

  Even so, it is still safe (albeit confusing) to use it by reference
  provided that the file starts with a proper copyright line and
  All rights reserved.  After all, our license simply spells out the
  conditions under which we reduce our own rights -- it doesn't matter
  whether or not the user can see the full agreement because without
  the agreement they cannot legally copy the file at all.

  Roy

/quote

I do not understand what Roy means by the scope of what was covered
beyond 'this file' Copyright law only protects the expression of an
idea, so I am baffled by what is meant by the scope beyond the file,
that is the written expression of the software developer. How can
copyright law apply to anything beyond the file?

Anyway, in the last paragraph Roy makes it clear that without the
licence the software cannot be legally copied. Thus, asserting the
Apache copyright in each file and referencing the Apache Software
License should be sufficient to protect our copyright.

What am I missing? Was there ever a closure to this question?



At 08:48 04.12.2002 +0100, you wrote:

On Wed, 4 Dec 2002, Darrell DeBoer [EMAIL PROTECTED] wrote:

 I don't know where it started, but if someone can someone tell me
 definitively that this is against ASF rules, I will move to rectify
 the situation.

Roy Fielding and several other board members have repeatedly stated
that the short version is not acceptable IIRC.  License 2.0 is
supposed to help.

Stefan

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]


--
Ceki

TCP implementations will follow a general principle of robustness: be
conservative in what you do, be liberal in what you accept from
others. -- Jon Postel, RFC 793



--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: Short Apache licence for source files

2002-12-04 Thread Ceki Gülcü
At 07:54 04.12.2002 +0100, Nicola Ken Barozzi wrote:

Currently we should use the full version.
There will be a short version of the next 2.0 license that will be equally 
protecting from a legal POV, but in the meantime use the full version.

Why? What is wrong with a copyright notice followed by a reference to
the license? The whole world does it. Why shouldn't we?


--
Nicola Ken Barozzi   [EMAIL PROTECTED]



--
Ceki

TCP implementations will follow a general principle of robustness: be
conservative in what you do, be liberal in what you accept from
others. -- Jon Postel, RFC 793



--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: Short Apache licence for source files

2002-12-04 Thread Ceki Gülcü
At 11:06 04.12.2002 +0100, Nicola Ken Barozzi wrote:


IANAL and not the one to decide.
IIRC IIUC the board, || board members have said to use the full version 
till version 2.0 arrives.

Well, as far as I know, there is no permission to use a reference to
the license although there is no explicit prohibition either.


You are free to take my word for it, or if you deem it necessary, go ask 
directly and eventually report back.

Michael A. Smith actually went to the board a few weeks ago. I did not
see a closure. As long as an ASF official (board, PMC) does not
officially take a position on this, or until there is an official
document on this topic, one should not make absolute affirmations.


--
Nicola Ken Barozzi   [EMAIL PROTECTED]


--
Ceki

TCP implementations will follow a general principle of robustness: be
conservative in what you do, be liberal in what you accept from
others. -- Jon Postel, RFC 793



--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: Short Apache licence for source files

2002-12-04 Thread Ceki Gülcü
At 12:13 04.12.2002 +0100, you wrote:



Ceki Gülcü wrote:

At 11:06 04.12.2002 +0100, Nicola Ken Barozzi wrote:


IANAL and not the one to decide.
IIRC IIUC the board, || board members have said to use the full 
version till version 2.0 arrives.
Well, as far as I know, there is no permission to use a reference to
the license although there is no explicit prohibition either.


You mean that everything can be done if it's not prohibited explicitly?
Come on, what's this, a policed community?



I was trying to convey that the word should has different meanings. It
can be interpreted as a recommendation or alternatively as an
obligation. For example,

1) One should brush one's teeth. Otherwise, you'll get bad
teeth. However, not brushing your teeth does not make you a bad
citizen.

2) One should be respectful of others. Being disrespectful or violent
makes you a bad citizen.

In 1) SHOULD is a recommendation whereas in 2) SHOULD really means MUST.

Thus, in the sentence, we should use include the license in each
file, does SHOULD mean MUST or is it just a recommendation?


You are free to take my word for it, or if you deem it necessary, go ask 
directly and eventually report back.
Michael A. Smith actually went to the board a few weeks ago. I did not
see a closure. As long as an ASF official (board, PMC) does not
officially take a position on this, or until there is an official
document on this topic, one should not make absolute affirmations.


My words: Currently we should use the full version.


Should or must? :-)


To stop this once and for all, since it seems that having a short license 
is very important for some (still don't know why), I've sent a request for 
clarification to the board too.

The license (version 1.1) is 41 lines long whereas the copyright notice 
plus the reference to the license is just 7 lines.

--
Nicola Ken Barozzi   [EMAIL PROTECTED]


--
Ceki

TCP implementations will follow a general principle of robustness: be
conservative in what you do, be liberal in what you accept from
others. -- Jon Postel, RFC 793



--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: Short Apache licence for source files

2002-12-04 Thread Ceki Gülcü
At 07:31 04.12.2002 -0500, Sam Ruby wrote:

Stefan Mainz wrote:

Ceki Gülcü wrote:


I do not understand what Roy means by the scope of what was covered
beyond 'this file' Copyright law only protects the expression of an
idea, so I am baffled by what is meant by the scope beyond the file,
that is the written expression of the software developer. How can
copyright law apply to anything beyond the file?

Propably i am not the right person to answer this (not being a lawyer), but:
If you refer to a file which includes the license and the license says
_this file_ the license applies to the license file, not the onw which 
referes to the file.

IANAL either.  My understanding matches Stefan's above.  If you include 
the current license by reference, the ASF appears to be well protected, 
but you may not be achieving what you want.  People who make use of the 
code you produce may some day be surprised to find that the only thing 
they actually have permission to make use of is the LICENSE FILE itself, 
subject of course to the terms contained therein.

OK, I think I understand slightly better but our license refers to
this software not to any specific file.

I think we all agree that referring to the license means that the
terms of the license apply, at least that is the intention.

There are three possible cases.

1) Bad faith interpretation

Someone decides that the license applies to the license file itself
and not to other files. If the license does not apply, then that
someone does not have the legal right to copy our software.

I think this is the case Roy was referring to in his comments -- the
comments I forwarded earlier without permission.

2) Good faith but cautious interpretation

In this case, someone is worried that the license applies to the
license file itself but not to other files. Thus, he or she decides
not use our software for fear of violating copyright law. Isn't this a
bit farfetched? Couldn't we address this concern in the license FAQ?

3) Intended interpretation

The Apache license applies even by reference as intended. No problems there.


The next license is intended to fix this.


Could we say referring to the license 1.1 is not recommended practice
but doing so does NOT make you a bad citizen?


- Sam Ruby


--
Ceki

TCP implementations will follow a general principle of robustness: be
conservative in what you do, be liberal in what you accept from
others. -- Jon Postel, RFC 793



--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: Gump changes

2002-11-12 Thread Ceki Gülcü

The Gump setup can be leveraged as a testing lab. I found the fact
that gump runs on machines in different timezones (at least in a
different timezone than mine) very valuable. This small difference has
allowed us to catch a timezone dependent bug  which we might
not have caught otherwise.

Runs on different JDKs, XML parsers, etc. adds to the testing lab
functionality of the current gump deployments (note the plural).

The above applies to junit tests not to formal compilation problems.

At 08:26 12.11.2002 -0500, Sam Ruby wrote:

Pier Fumagalli wrote

So I'm wondering why the heck I'm running that thing 4 times a day,
if at the end, no one uses it...


It should only be run on Nagoya twice a day.  As a general rule, builds 
have the most success on a Linux/intel machine, so that's the one that I 
call the official one.

It is very helpful to have gump run more than once a day so that people 
who are making changes that they don't *think* will impact others have an 
opportunity to verify this before all sorts of nag messages go out.

So, gump runs every 6 hours spread across 3 machines.

- Sam Ruby


--
To unsubscribe, e-mail:   mailto:general-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:general-help;jakarta.apache.org


--
Ceki

TCP implementations will follow a general principle of robustness: be
conservative in what you do, be liberal in what you accept from
others. -- Jon Postel, RFC 793



--
To unsubscribe, e-mail:   mailto:general-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:general-help;jakarta.apache.org




Re: Differences between Structs and Turbine ???

2002-10-08 Thread Ceki Gülcü

At 12:07 08.10.2002 -0700, Jon Scott Stevens wrote:

I recently spent a couple weekend nights and built the StudioZ.tv website in
PHP4 on OSX. It is a pretty cool webapp that has really transformed things
for us and made my life MUCH easier (the office staff can fully manage the
events that show up on the website via a browser). I incorporate several
technologies into the site (including a cool XML-RPC interface that talks to
presaleticketing.com to tell us how many tickets have been sold). I used PHP
because it was quick and easy and I didn't have time to 'design' the
application.

The only thing that sucks is that the code is a complete hack that is going
to be terrible to maintain over the long term and half the time, I can't
figure out why something does or doesn't work.

It is surprising that a Java expert with monumental contributions to
this community would not use Java technology to create his website. Is
this a case of do as I say, not as I do?

Of course one is free to try new approaches but the anecdote is still quite
telling. Cool-looking site by the way.

=)

-jon

--
StudioZ.tv /\ Bar/Nightclub/Entertainment
314 11th Street @ Folsom /\ San Francisco
 http://studioz.tv/

--
Ceki

TCP implementations will follow a general principle of robustness: be
conservative in what you do, be liberal in what you accept from
others. -- Jon Postel, RFC 793



--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




log4j-dev@ summary for June

2002-06-28 Thread Ceki Gülcü


Rob,

Thank you for the Jakarta Newsletter initiative. I am looking forward to 
the June issue.

Here is the log4j submission.

This file contains the summary of what has been discussed on the
log4j-dev@ mailing lists. Its monthly contents are sent to the editor
of the Jakarta Newsletter. For the first issue of the Jakarta
Newsletter see:

   http://marc.theaimsgroup.com/?l=jakarta-generalm=102328546509220w=2

+==+
|June 20002|
+==+

The month started with a question by John Armstrong [1] on whether
log4j offered any guarantees on binary compatibility between various
versions.  To which Ceki replied by stating [2] the current policy of
not removing deprecated methods until at least two release cycles are
completed. This reply did not seem to satisfy John Armstrong and a
long discussion ensued. A historical perspective [3] seemed to satisfy
most people, at least the discussion petered off.

[1] http://marc.theaimsgroup.com/?l=log4j-devm=102335790906496w=2
[2] http://marc.theaimsgroup.com/?l=log4j-devm=102336327109965w=2
[3] http://marc.theaimsgroup.com/?l=log4j-devm=102387540521717w=2

Mike Agnus started [4] a discussion about timezone and locale related
issues in log4j date formats. James Cakalic and Mike discussed the
importance of the decimal character separator.  Possible performance
improvements were also suggested. Mark Womack submitted code for
timezone support for date elements of pattern layout. Unfortunately,
the code was anonymous and we could not take into consideration.  The
idea seemed to catch on though.

[4] http://marc.theaimsgroup.com/?l=log4j-devm=102209832808942w=2
[5] http://marc.theaimsgroup.com/?l=log4j-devm=102420694310844w=2

Ceki asked for clarifications [6] on java buffered IO because his
experience did not match the myth. Georg Lundesgaard mentioned [7] the
character conversion buffering aspect as explained in the
OutputStreamWriter javadocs.

[6] http://marc.theaimsgroup.com/?l=log4j-devm=102326443025158w=2
[7] http://marc.theaimsgroup.com/?l=log4j-devm=102327620700816w=2

Costin Manolache related his experience [8] with configuring log4j
with JMX. He mentioned the web-application logging insulation
problem. In response, Ceki wrote a specification [9] for solving the
logging separation problem. This was followed by a promising
discussion [10] on Tomcat-dev.

[8]  http://marc.theaimsgroup.com/?l=log4j-devm=102412323003656w=2
[9]  http://qos.ch/containers/sc.html
[10] http://marc.theaimsgroup.com/?t=10251038101r=1w=2

Mark made a proposal [1]] for a new log4j component called Receiver.

[11] http://marc.theaimsgroup.com/?l=log4j-devm=102523926310678w=2


--
Ceki


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: welcoming and nurturing volunteers

2002-05-25 Thread Ceki Gülcü

At 23:30 24.05.2002 -0400, Sam Ruby wrote:
http://www.libertyforall.net/2002/archive/do-ocracy.html

The motivational power of appreciation cannot be underestimated. The
author is correct in emphasizing the point. What is not emphasized
enough is the need for direction. What's the use of having a million
volunteers if they all pull in different directions?

- Sam Ruby

--
Ceki


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: welcoming and nurturing volunteers

2002-05-25 Thread Ceki Gülcü

At 10:07 25.05.2002 -0400, you wrote:
Ceki Gülcü wrote:
 
  The motivational power of appreciation cannot be underestimated. The
  author is correct in emphasizing the point. What is not emphasized
  enough is the need for direction. What's the use of having a million
  volunteers if they all pull in different directions?

Apache projects tend to attract an abundance of leaders.

I was not thinking of Apache or Jakarta.  My reading of the
article was if you make your volunteers warm and cozy everything will
be fine which is just wishful thinking.  I admit that this is an
incomplete reading of the Sean Haugh's article given that the issue of
leadership and direction is implied throughout the article--the
keyword here is implied.

- Sam Ruby

--
Ceki


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: Criteria for commit access

2002-05-24 Thread Ceki Gülcü

At 18:31 24.05.2002 -0400, Sam Ruby wrote:

* Perhaps a more fruitful topic for us to explore is when to retire
committer status due to inactivity.  Pier is one of the few to do this
explicitly.  I have done it a bit more implicitly - including submitting
patches to projects that I am officially a committer to.


I find that submitting a patch and let someone else apply it to
projects where you are active (and a committer) has several
advantages.

It says: hey look what I have created. What do you think?
Submitting a patch is more likely to elicit active comments.

It is also a sign of respect. You know you can do it. The other
developers know you can do it; but by not doing it you encourage the sense
ownership of another developer (the one who will apply the patch) for
that part of the code where the patch will go.

Obviously, this sort of dancing becomes unnecessary when you have a
close and trusting relationship with the other developer(s) although
establishing trust takes time. It does not happen overnight.

- Sam Ruby

--
Ceki

ps: By the way, the idea of submitting a patch as a committer is not
mine. It's yours (Sam's).


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




bugzilla related emails

2002-05-16 Thread Ceki Gülcü


Hello,

The log4j developers would like log4j bug report related emails to
also appear on the log4j-dev mailing list. Can this be done?

Sorry for the noise, I am just trying to follow the instructions found
at http://jakarta.apache.org/site/bugs.html:

   Pier Fumagalli has set up the Apache Bug Database. Please use this
   database report bugs and suggest new features. To suggest a new
   feature, set the severity of the bug to enhancement. In case of
   problems with the Apache Bug Database, please notify
   [EMAIL PROTECTED]

Thanks in advance, Ceki


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: bugzilla related emails

2002-05-16 Thread Ceki Gülcü

At 09:32 16.05.2002 +0200, Stefan Bodewig wrote:
On Thu, 16 May 2002, Ceki Gülc [EMAIL PROTECTED] wrote:

  The log4j developers would like log4j bug report related emails to
  also appear on the log4j-dev mailing list. Can this be done?

All that needs to be done is changing the default owner for the
components (which means you wouldn't be getting the reports to your
personal address any longer).  I don't know whether it is possible to
define automatic CCs in addition to default owners.

Do you have enough karma to change the default owner of the Log4J
components?  If not, I can do that for you.

In fact I have enough karma. I just did the change you suggested. The
only glitch was that the password for log4j-dev goes to
[EMAIL PROTECTED] Fortunately,
[EMAIL PROTECTED] is not subscribed to itself such that the
list moderators could intercept the password before it got public.

By the way, thanks for your prompt offer for help.

Stefan

--
Ceki


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: [New Subproject Proposal] ObjectBridge

2002-05-01 Thread Ceki Gülcü


Here is my enthusiastic but non binding +1.

At 14:41 29.04.2002 -0400, you wrote:
Hi,

I would like to propose ObjectRelationalBridge
(http://objectbridge.sourceforge.net/) as a top level subproject of
Jakarta.

--
Ceki


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: Large code donation?

2002-04-12 Thread Ceki Gülcü


The results of a recent vote show that the log4j community has strong interest
in the donation. Is there  a document that I can present to the donator for 
signature?
I assume this document is NOT the Contributor License Agreement because
that document  applies to individuals, not corporations. Correct? To whom do I
(or the donator) send the signed document? Thanks in advance, Ceki

At 23:58 11.04.2002 +0200, [EMAIL PROTECTED] wrote:

There are several reasons why this needs a contributors license (assuming
people want the code)

--
Ceki


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Large code donation?

2002-04-11 Thread Ceki Gülcü


Hi all,

A commercial company, after changing its business orientation, recently 
proposed to
donate a rather large chuck of code, essentially a log4j extension, to the 
log4j project.
Do we need to have them sign  any paperwork? Assuming they post the source 
code
(under the Apache Software License)  to the log4j-dev list, can we then 
consider that
the contribution is just a large patch?

Any clarification on this matter would be greatly appreciated.

--
Ceki


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: Large code donation?

2002-04-11 Thread Ceki Gülcü


Your explanation is crystal clear. I'll organize a vote on the
donation just to make sure that we really want the code. Thanks again, Ceki

At 23:58 11.04.2002 +0200, [EMAIL PROTECTED] wrote:

On Thu, 11 Apr 2002, Ceki [iso-8859-1] Gülcü wrote:

  A commercial company, after changing its business orientation, recently
  proposed to donate a rather large chuck of code, essentially a log4j
  extension, to the log4j project. Do we need to have them sign any
  paperwork? Assuming they post the source code (under the Apache Software
  License)  to the log4j-dev list, can we then consider that the
  contribution is just a large patch?
 
  Any clarification on this matter would be greatly appreciated.

There are several reasons why this needs a contributors license (assuming
people want the code)

-   Whoever post the patch cannot claim he has written
 it himself
-   And since it is clearly associated with a commercial
 company - that person cannot easily claim he or she
 owns it 100%
-   Nor do we have a clear relation (committer, member)
 with that person.

So each of those is an indiactor that you propably want to go through the
contributor license hassle. The PMC or board can help you.

Feel free to ask for a hand.

But of course you do want to make sure that the log4j community
actually wants that code !

Dw


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

--
Ceki


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: Comments on the commons-logging API

2002-03-29 Thread Ceki Gülcü


Wait a minute, I know you... You are the apricot
(http://sourceforge.net/projects/apricot/) guy. In the fairy tale The
Emperor's new clothes, what was the name of the child who calls

 He's naked. The man in the crown is naked

Was it Vladimir Bossicard?


At 18:28 28.03.2002 -0800, you wrote:
god no. The avalon group was already using a facade logger long before 
commons was for much the same reason commons adopted one.


Is Avalon still using its own facade logger or changed to commons-logging?

I'm just wondering: How many Jakarta projects use this common-logging 
package?  What's the advantage of having a common logging package if it's 
not widely used even within the Jakarta community?

One solution: all Jakarta projects must support both LogKit and Log4J (as 
they are both part of the family) by using commons-logging if they want to 
(but as logging is not the core business of many Jakarta projects, using 
the common-logging package makes sense).

Another solution : drop one logger (don't shoot me!) and stand beside the 
winner.  Users willing to use Jakarta projects will *have* to use the 
Jakarta logger.  Sound M$-ish, doesn't it?

Last solution : everyone stands where they are: pro-choice vs. pro-one-logger.

-Vladimir

--
Vladimir Bossicard
www.bossicard.com

--
Ceki

My link of the month: http://java.sun.com/aboutJava/standardization/


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: Comments on the commons-logging API

2002-03-29 Thread Ceki Gülcü


The interesting case is of course measuring performance when logging is
turned off. Here is a little experiment.

My CLASSPATH:

CLASSPATH=.;/java/jdk1.3.1/jre/lib/rt.jar;/home/cgu/ASF/jakarta-log4j-1.2beta4/dist/lib/log4j-1.2beta4.jar;commons-logging-1.0/commons-logging.jar


I have written two short programs that log in a loop. One called
Direct.java log that directly uses log4j. The other, called Indirect.java,
logs indirectly using commons-logging.

-
import org.apache.log4j.Logger;
import org.apache.log4j.Level;

public class Direct {

   public static void main(String args[]) {

 if(args.length != 1) {
   System.err.println(Usage: java Direct runLength\n +
 where runLength is an int representing the run length of loops\n+
   I suggest a runLength of at least 100'000.);
 }

 int runLength = Integer.parseInt(args[0]);

 Logger logger = Logger.getLogger(bandicoot);

 // disable all logging below INFO.
 logger.getLoggerRepository().setThreshold(Level.INFO);

 long begin = System.currentTimeMillis();
 for(int i = 0; i  runLength; i++) {
   if(logger.isDebugEnabled()) {
 logger.debug(This is message + i);
   }
 }

 long end = System.currentTimeMillis();
 double totalMicros = (end-begin)*1000.0;
 System.out.println(Average time: +totalMicros/runLength+ in 
microseconds.);
   }
}
---

Here is Indirect.java

---
import org.apache.commons.logging.LogFactory;
import org.apache.commons.logging.Log;

public class Indirect {

   public static void main(String args[]) {

 if(args.length != 1) {
   System.err.println(Usage: java Indirect runLength\n +
 where runLength is an int representing the run length of loops\n+
   I suggest a runLength of at least 100'000.);
 }

 int runLength = Integer.parseInt(args[0]);

 Log log = LogFactory.getFactory().getInstance(bandicoot);

 // notice that in this example there is no code to set the level
 // of the repository.

 long begin = System.currentTimeMillis();
 for(int i = 0; i  runLength; i++) {
   if(log.isDebugEnabled()) {
 log.debug(This is message + i);
   }
 }

 long end = System.currentTimeMillis();
 double totalMicros = (end-begin)*1000.0;
 System.out.println(Average time: +totalMicros/runLength+ in 
microseconds.);
   }
}
---

Running Direct I get:

~/ java Direct 1
Average time: 0.01903 in microseconds.

Running Indirect I get:

~/ java Indirect 1
log4j:WARN No appenders could be found for logger (bandicoot).
log4j:WARN Please initialize the log4j system properly.
Average time: 1.15155 in microseconds.

That's a factor of 60 and not in percents!

Of course, I cheated because Indirect.java does not configure
the repository threshold.

Placing a file called log4j.properties with the following contents

   log4j.threshold=WARN
   log4j.debug=true

in the *current* directory (remember I have '.' as the first entry in
my CLASSPATH) and running Indirect java I get:

~/  java Indirect 1
log4j: Parsing threshold string [WARN]
log4j: Could not find root logger information. Is this OK?
log4j: Finished configuring.
Average time: 0.02854 in microseconds.

That's an increase of 50, but in percents this time. Interestingly,
enough the results are very similar in JDK 1.2.2; the numbers change
but the proportions don't.

Moral of the story? You are essentially right if the user knows what
she is doing.

It would be interesting to see if changing

  private Category category = null;

to

  final private Category category;

in org.apache.commons.logging.impl.Log4JCategoryLog would
change anything. It would be a nice experiment.

At 12:46 29.03.2002 +1100, you wrote:
On Fri, 29 Mar 2002 12:38, Ceki Gülcü wrote:
  1) logging calls are made thousands of times so the indirection through
  an equalizer API (like commons-logging) has a performance impact

Not in modern JVMs (read most almost all jdk1.3 impls).

As long as the underlying indirection (ie between commons and Log4j) is done
via a final variable then the cost is zero due to JVM optimizations. Theres
still the cost of the dynamic dispatch between user land code and commons
code but that cost is very very minimal compared to the rest of the logging
operations.

The cost comes in constructing the string objects (which is literally
thousands times more expensive than a dynamic dispatch) and routing the log
message.

As long as the API supports functions like isDebugEnabled() (which I believe
commons does? or at least did) then the performance cost is so negligable to
be unimportant.

In one word? Yes.


--
Ceki
My link of the month: http://java.sun.com/aboutJava/standardization/


--
To unsubscribe, e-mail:   mailto

Re: Comments on the commons-logging API

2002-03-29 Thread Ceki Gülcü


Good point, except that the loop length was 100'000'000 so the cost of the
first 10'000 calls would be dwarfed by the remaining 99'990'000. Of course
there is also:

~/java Indirect 1
log4j: Parsing threshold string [WARN]
log4j: Could not find root logger information. Is this OK?
log4j: Finished configuring.
Total: 0.0 in microseconds.
Average time: 0.0 in microseconds.

Point well taken nonetheless.

At 22:01 29.03.2002 +1100, you wrote:
Try changing your code to loop 10,000 times or so before you start the real
test. This will make sure the JVMs are warmed up and all systems are
configured properly. That should drop the difference even more in theory.

--
Ceki

My link of the month: http://java.sun.com/aboutJava/standardization/


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: Comments on the commons-logging API

2002-03-29 Thread Ceki Gülcü

At 18:28 28.03.2002 -0800, you wrote:
god no. The avalon group was already using a facade logger long before 
commons was for much the same reason commons adopted one.


Is Avalon still using its own facade logger or changed to commons-logging?

I'm just wondering: How many Jakarta projects use this common-logging 
package?  What's the advantage of having a common logging package if it's 
not widely used even within the Jakarta community?

One solution: all Jakarta projects must support both LogKit and Log4J (as 
they are both part of the family) by using commons-logging if they want to 
(but as logging is not the core business of many Jakarta projects, using 
the common-logging package makes sense).

Another solution : drop one logger (don't shoot me!) and stand beside the 
winner.  Users willing to use Jakarta projects will *have* to use the 
Jakarta logger.  Sound M$-ish, doesn't it?

Last solution : everyone stands where they are: pro-choice vs. pro-one-logger.

Your allusion to Microsoft is interesting as much as it is troubling. For 
some reason
everybody here takes the development of good software for granted. It takes 
a lot of
energy and time. We waste much of it bickering among ourselves. Initially I was
very saddened by this but now have grown accustomed to it. I do not expect
to change anyones's mind. I am pretty sick of the politics and have much work
to do.


--
Ceki
My link of the month: http://java.sun.com/aboutJava/standardization/


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




RE: Comments on the commons-logging API

2002-03-29 Thread Ceki Gülcü

At 15:36 29.03.2002 +, Danny Angus wrote:

  Now that you can (well, soon) legally implement JSR47's, you
  might was well
  support their interfaces and semantics, and then 'embrace and
  extend'.  Just
  do the JSR47 stuff better :)

Could Log4J now become an RI of JSR47 ? (I'm still not completely clear
about all this..)

No, it cannot. JSR47 is not an some network protocol or an abstract
description of an interface, coding rules etc. It is a nuts and bolts
implementation.

Jason Hunter also mentioned some rule about being part of the
JDK 1.4 umbrella JSR which apparently changes things. (Don't
ask me why.)


--
Ceki
My link of the month: http://java.sun.com/aboutJava/standardization/


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: Comments on the commons-logging API

2002-03-28 Thread Ceki Gülcü

At 15:10 28.03.2002 -0600, Morgan Delagrange wrote:
Where is this world where everyone uses Log4J?

That world = (world - jakarta)


--
Ceki
My link of the month: http://java.sun.com/aboutJava/standardization/


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: Comments on the commons-logging API

2002-03-28 Thread Ceki Gülcü

At 15:30 28.03.2002 -0600, Morgan Delagrange wrote:

I am pro-Log4J.  I wish I lived in that Log4J-only world (until/unless
something better came along).  Generally, commons-logging neither encourages
nor discourages use of Log4J.  However, I would argue that it _does_
encourage Log4J a bit by not forcing a logging implementation war.

True. It does encourage it, but only initially. On the long run,
however, people will run into problems with their logging (as is
happening now). They will say this commons-logging+log4j stuff is too
complicated, we'll switch to JDK 1.4 logging, at least that does not
have any CLASSPATH problems.

The fact is, JDK 1.4 logging in particular is going to become more and more
common over time, and unless someone can summon forth a magic recantation of
that JSR, then a component-level interface with popular loggers is
necessary.  Otherwise you have to pick, which only services us at the
expense of those who use other logger implementations.

Possible but I would not be that sure.  We will have very strong new
features in log4j 1.3 (the release after 1.2) which will leave JDK 1.4
logging even further behind.  Just as importantly, log4j documentation
is going to get a massive boost with the upcoming log4j book.

Sun's me-too strategy is bound to fail. The question is whether the
bigger jakarta community is going to help us defeat JSR47 or stand in
the way.

--
Ceki
My link of the month: http://java.sun.com/aboutJava/standardization/


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: Comments on the commons-logging API

2002-03-28 Thread Ceki Gülcü

At 16:33 28.03.2002 -0600, you wrote:
  Sun's me-too strategy is bound to fail. The question is whether the
  bigger jakarta community is going to help us defeat JSR47 or stand in
  the way.

That's a bit harsh, isn't it?

Hmm, maybe it is. What I am trying to say is that I would have liked
to see jakarta present a more united front. Well, too bad...

--
Ceki
My link of the month: http://java.sun.com/aboutJava/standardization/


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: Comments on the commons-logging API

2002-03-28 Thread Ceki Gülcü


Costin,

I think you have done a pretty good job on the log4j wrapper. However,
I am pretty stretched out as it is, so I can't really help with something
I don't particularly like. Besides, if people find commons-logging really 
useful
they will build a community around it. What I say or think won't matter.

At 15:17 28.03.2002 -0800, you wrote:
On Thu, 28 Mar 2002, Ceki Gülcü wrote:

  True. It does encourage it, but only initially. On the long run,
  however, people will run into problems with their logging (as is
  happening now). They will say this commons-logging+log4j stuff is too
  complicated, we'll switch to JDK 1.4 logging, at least that does not

And you are the only one who can make commons-logging + log4j to be
the best solution on the long run.

By implementing and maintaining the log4j implementation of
commons-logging.

The API is a subset of log4j, and if you really want to help the users
all you have to do is take ownership of a log4j implementation of
commons-logging.

It doesn't even have to be included in commons-logging, it is
better if each log4j impl. had it's own implementation of the wrapper,
possibly taking advantage of new features, etc.

Costin

--
Ceki
My link of the month: http://java.sun.com/aboutJava/standardization/


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




RE: Comments on the commons-logging API

2002-03-28 Thread Ceki Gülcü

At 00:57 29.03.2002 +0100, Paulo Gaspar wrote:
Ceki,

What about making clear that commons-logging is only supposed to be
used by other components so that the application developer picks
the logging API that suits him best?

That seems to be the intent of commons-logging. I have pointed out
the problems with that approach.

Do you really believe that all application developers will use
Log4J? Or do you want to force them into doing that?

I can't force people to do anything.

Do you have any doubt that lots of companies will follow the policy
of using the JDK 1.4 Logging API just because it is the one that
comes with Java?

Yes, I have my doubts. It still takes a human brain to program a
computer. This is not different in Java. This fact is to remain valid for the
foreseeable future.

Do you really think that the persons imposing such decision will
care about what is good and what is bad?

Yes. People have brains.

And then the ones getting the mess will be the developers and the
commons-logging will help those. And will also help them to use
the components/libs that use it.

Possibly.

This sounds like just another of your pro-log4j-anti-anything-else
campaigns, containing the usual amount of FUD of any blind campaign.

Please avoid making generalizations.

A blind campaign is one where the single motivation of the
campaigner is defending some interest/belief against all others...
without really trying to SEE or get precise information on what
those others really are.

I have a right to speak my mind as much as you do.

The blindness towards the other alternatives tends to grow a
considerable amount of misinformation on the blind campaigner and,
then, he vigorously spreads it - hence the resulting spread of FUD.

You seem to be following a pattern here, since you are doing just
the same as you usually do against LogKit, including the
misinformation bit.

Although both you and Peter turn a bit silly when under the
influence of another-logger-war, I always notice that you know much
less about LogKit than Peter knows about log4j. (And yes, I know
both well enough to clearly notice that).

The issue with LogKit is entirely different. The current debate is
perhaps tense  but well within the bounds of mutual respect and
civility. I made my reservations about the commons-logging API
and its developers presented their counter arguments.

It is sad that you show to be more interested on destroying the
competition than on learning from it. Well, at least you did not
accuse the commons-logging guys from plagiarism just yet, as you
did about the LogKit guys.

I never suspected (nor suggested) that commons-logging effort was
dishonorable in any way. My contention is that it will make life harder
not easier. Nothing more, nothing less.

  -Original Message-
  From: Ceki Gulcu [mailto:[EMAIL PROTECTED]]
  Sent: Thursday, March 28, 2002 11:14 PM
  To: Jakarta General List
  Subject: Re: Comments on the commons-logging API
 
 
  At 15:30 28.03.2002 -0600, Morgan Delagrange wrote:
 
  I am pro-Log4J.  I wish I lived in that Log4J-only world (until/unless
  something better came along).  Generally, commons-logging
  neither encourages
  nor discourages use of Log4J.  However, I would argue that it _does_
  encourage Log4J a bit by not forcing a logging implementation war.
 
  True. It does encourage it, but only initially. On the long run,
  however, people will run into problems with their logging (as is
  happening now). They will say this commons-logging+log4j stuff is too
  complicated, we'll switch to JDK 1.4 logging, at least that does not
  have any CLASSPATH problems.
 
  The fact is, JDK 1.4 logging in particular is going to become
  more and more
  common over time, and unless someone can summon forth a magic
  recantation of
  that JSR, then a component-level interface with popular loggers is
  necessary.  Otherwise you have to pick, which only services us at the
  expense of those who use other logger implementations.
 
  Possible but I would not be that sure.  We will have very strong new
  features in log4j 1.3 (the release after 1.2) which will leave JDK 1.4
  logging even further behind.  Just as importantly, log4j documentation
  is going to get a massive boost with the upcoming log4j book.
 
  Sun's me-too strategy is bound to fail. The question is whether the
  bigger jakarta community is going to help us defeat JSR47 or stand in
  the way.
 
  --
  Ceki
  My link of the month: http://java.sun.com/aboutJava/standardization/
 


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

--
Ceki

My link of the month: http://java.sun.com/aboutJava/standardization/


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




RE: Comments on the commons-logging API

2002-03-27 Thread Ceki Gülcü

At 11:49 27.03.2002 -0600,  Rodney Waldhoff wrote:

But this isn't really the reason commons-logging was created.  Note that
most of the commons components are just that--tiny libraries meant to be
integrated/incorporated into larger frameworks and larger applications.
Some of these components need/want logging capabilities, or at least some
people need/want some components to have logging capabilities.  But it seems
a obtrusive for some tiny library to dictate the logging framework (if any)
that should be used by the larger application that contains it.  So the
component is stuck with a decision between not using logging at all, or
forcing some standard logging implementation upon the larger framework,
and the containing application is stuck with either converting everything to
this standard logging implementation (and hoping that each component
agrees on what that is) or having a heterogeneous set of logs and logging
implementations.  Search-and-replace code switching isn't really an option
for the commons components, or at least not a terribly good one.

If your library chooses to use logging API XYZ, this does not impose
XYZ to the clients of your library. Your clients can use the logging
library they prefer (if they are using logging API) and your library
can use XYZ. One choice does not necessarily influence the other. For
example, the fact that JBoss uses log4j does not impose a logging
library to the bean developer. Similarly, Tomcat's logging library
does not prevent web-app developers from using log4j.

In other words, the argument about (jakarta-commons) components
dictating a logging API to the containing application is widely
accepted although very dubious in my opinion.

Anyway, I think we have been through all this already. I do not expect
to be able to convince anyone altough I suspect uncertainty and the
bug reports will, slowly but surely.

Commons-Logging is meant to provide an alternative solution: create a
facade/adapter around an arbitrary logging API, use it at the common
component level, and allow the user (the containing application) to select
which specific logging implementation (if any) to use.  Then the same binary
works everywhere, and in many (most?) cases, the commons-logging will just
quietly do what you hope it would. (If you've got log4j, it uses it. If
you've got JDK 1.4, it uses that. If all else fails, it doesn't do
anything.)

I don't think hoping quitely and computers get along very well.

An arbitrary application or system shouldn't feel compelled nor even
(necessarily) encouraged to use commons-logging. That's not what it's there
for.  It's there to allow the library components to delegate that decision
to the containing application.

I understand your argument. I have already exposed mine. Thanks for your
attention. Ceki



--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: Comments on the commons-logging API

2002-03-27 Thread Ceki Gülcü

At 15:18 27.03.2002 -0600, Morgan Delagrange wrote:
Here's the problem, as I see it.

Suppose Commons component A decides to adopt Log4J, Commons component B
decides to adopt LogKit, and Commons component C adopts JDK1.4 logging.
They will all minimally function with the right jars in the classpath.
However you (the end-user) are left with maintaining configuration for 3
different logging APIs, which is tedious at best.  When you take into
account cool features like variable log levels, Log4J appenders and the
like, you're pretty much guaranteed to swallow up useful configuration
options because sophisticated configurations are too difficult to maintain
over mutiple logging implementations.

Contrarily, if all three Commons components use a logging facade, you can
focus all your configuration efforts on one logging implementation.  Sure,
there is a trade-off; you don't have access to all the features, and the
interface between the facade and the implementation must be maintained.  But
the benefits are not just political; they potentially make the end-users
configuration much easier.

So, if I understand correctly the reason for adopting commons-logging
API is for convenience rather than non-intrusiveness as a library
(with respect to logging).

With commons-logging, the end user will only have to configure the
logging API that common-logging selects (or detects) but the selection
mechanism is dynamic such that there are many ways and reasons for
which the selected API will be the wrong one. This is the uncertainty
factor I am talking about.  Uncertainty breeds confusion and confusion
breeds despair.


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: Comments on the commons-logging API

2002-03-27 Thread Ceki Gülcü

Costin, Morgan, Rodney,

Thanks for the lively discussion and sharing your points of view. My intent
was to warn users of the dangers of using common-logging. I have done
my bit. Cheers, Ceki

At 16:31 27.03.2002 -0600, Morgan wrote:
I believe the order of precedence is well documented.  I think the logging
component would benefit from warning messages when a default implementation
is selected (like Log4J warns you when there is no log4j.properties file
available), but this doesn't require any fundamental change to the API.

If you want to take about confusion and despair, look at the environment
that's running three logging implementations simultaneously.

- Morgan

--
Ceki
My link of the month: http://java.sun.com/aboutJava/standardization/


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Comments on the commons-logging API

2002-03-26 Thread Ceki Gülcü


Hello all,

Given that log4j is such a low-level library, most organizations are
suspicious to tie their code to log4j, especially considering the new
logging API in JDK 1.4.

Before going forward, it is appropriate to mention that these two APIs
are very similar.  The classical usage pattern for log4j is:

---

import org.apache.log4j.Logger;

public class MyClass {
   final static Logger logger = Logger.getLogger(some.name);

public void foo1() {
  logger.debug(Hello world.);
}

public void foo2() {
  logger.info(Another message.);
  logger.error(Stop that!, new Exception(The earth is getting 
warmer.));
}
}
---

As you are well aware by now, one of the important benefits of log4j
is that it can be configured at run time using configuration scripts.
You can have hundreds or thousands of log statement but only one or
two lines of code to configure log4j.

The usage pattern for the JDK 1.4 logging API is:

---
import java.util.logging.Logger;

public class MyClass {
final static Logger logger = Logger.getLogger(test);

public void foo1() {
  logger.debug(Hello world.);
}

public void foo2() {
  logger.info(Another message.);
  logger.error(Stop that!, new Exception(The earth is getting 
warmer.));
}
}
---

Do you notice anything similar? The JDK 1.4 logging API also admits
configuration scripts. Being part of the JDK, the common guess that
this API will supplant log4j some time in the future.

It is not so easy to write a complete logging API. Users
come to realize they need the features present in log4j but absent in
JDK 1.4 logging API.  Moreover, log4j runs with JDK 1.1 or later whereas
the JDK 1.4 logging API, requires, well, JDK 1.4.  Most users can't
afford to tie their code to JDK 1.4.

But they need logging and they need it now. A common strategy for
protecting against future changes and at the same time to benefit from
existing log4j features is to *wrap* log4j with a custom logging
API. Log4j actually has support to facilitate such wrappers.

It turns out that such wrappers are not that trivial to write. I frequently
receive email where a user runs into a problem with their wrapper and
requests help. More often than not, these wrappers are of poor quality
such that the cost of inactive (or disabled) logging statements is
multiplied by a factor of 1'000.

Of course, not all wrappers are of poor quality. For example, the
commons-logging API is rather well implemented. Obviously, there is
still a cost for the wrapping but it won't be of a huge factor.

The commons-logging API will try to use the JDK 1.4 API if present, or
the log4j API. The *current* preference is log4j I believe. Neat!

Now, it just happens that the part where most users have difficulty is the
initialization of the log4j API. Where should the log4j.jar go? Where
do I put the log4j.properties files?  Can I have different
web-applications have different log4j configurations?  How do I
initialize log4j in an application server?  Although there is ample
literature on the subject, much confusion remains.

The commons-logging API as it wraps multiple logging APIs such
as Avalon's LogKit, log4j, JDK 1.4 has its own discovery process.
Things were confusing before, they will be even more when
commons-logging API enters common usage. With some effort, it might
start making sense to you. However, your users will not show the same
perseverance nor enthusiasm.

There will be also unexpected interactions between log4j and the
commons-logging API. For example, log4j 1.2alpha1 through alpha4 had a
very subtle bug which caused client code compiled with log4j version
1.1.3 to throw exceptions when ran with log4j 1.2alpha. Inversely,
code compiled with 1.2alpha would crash when ran using log4j 1.1.3.
This problem was fixed in log4j beta.

It is now sufficient for client code to be compiled with 1.1.x and to
run with 1.2 beta without problems and vice versa. Of course if
commons-logging compiled with log4j 1.2alpha the problem would be
sticky. It would not go away by compiling client code but only by replacing
the commons-logging API.

In the recent weeks I have also started to receive disturbing bug reports
where components using commons-logging API behave strangely.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7484
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6764

I suspect that these problems will only worsen in the future. The
commons-logging developers will suspect a log4j bug and we will
suspect a commons-logging API bug. By increasing the number of
components required for logging you have doubled the probability of
bugs while the difficulty of resolving them has increased by a higher
multiple.

Remember that the initial goal of 

Re: Now what? (was: Jakarta Overview)

2002-03-23 Thread Ceki Gülcü

At 14:47 22.03.2002 -0800, you wrote:

- Audience and Marketing:
The document is directed towards people who may not be familiar
with all the projects that exist under the Jakarta umbrella.
Specifically, it is directed towards users, who hope to find
something useful for their own projects. (Those users may turn
into contributors over time!)
I cannot understand why Leo and Ceki refer to the document (and,
by implication, others like it) as Marketing - a term which
carries in this context clearly condescending connotations.
I don't think documentation is marketing - and what I tried to
provide is simply documentation, not different in principle
than Javadoc, only at a higher level.

I realize that you spent considerable amount of time editing
the document. I appreciate the effort. I assure you that there is
no condescension on my part, at least not intentional.

The introduction in your email came through as here is the
solution to all Jakarta's problems. I have a hard time accepting
that as being the truth.

It is also simply not true, as Ceki believes, that everybody
knows Jakarta: from the inside it may be hard to conceive how
large and confusing the entire Jakarta project can appear to
the outsider.

The Jakarta brand is very well known. What is less known are the
individual Jakarta subprojects, in particular their relation with each
other.  I doubt the overview document will solve that conundrum.

As I said in my previous comments, I do not have a problem with the
contents of the document per se but the sprit in which it was
presented. IMO, it would have been preferable to work with each
individual subproject rather than start a new body of work but that was
not my decision to make.

Are you willing to continue maintaining it? Make sure that it is
comprehensive, consistent and up to date? What will happen when you
grow tired of it?

Nothing is preventing you from continuing to work on the
overview.  If you persist, my -1 will be withdrawn or overridden. What
is certain is that the overview is yet another brick on of the edifice
of Jakarta.


Philipp K. Janert, Ph.D.  [EMAIL PROTECTED]

--
Ceki

My link of the month: http://java.sun.com/aboutJava/standardization/


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: [VOTE] ASL vs. GPL page: is this okay?

2002-03-06 Thread Ceki Gülcü
 then will automatically apply to our
   software. Although we do not expect the Free Software Foundation of
   making changes that deviate from the spirit of the current versions,
   they could make clarifications that are contrary to our
   intentions. For example, they may clarify that the result of
   aspect-oriented weaving is subject to the terms of the LGPL, whereas
   we had intended that it is not. Another concern is who will be in
   charge of the Free Software Foundation 10 years from now, or what
   happens if the Free Software Foundation is discontinued? [LGPL,
   section 13]

Licensing is a blackhole for time. It also happens to be central element in
open source development. Its importance cannot be overstated.


--
Ceki Gülcü


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




RE: [VOTE] ASL vs. GPL page: is this okay?

2002-03-06 Thread Ceki Gülcü



At 16:17 06.03.2002 -0600, you wrote:
-1

I'm not sure we need this at all.

I disagree. I think we definitely need a solid document countering the 
idyllic but false world depicted
by the FSF. It's just a gargantuan task to come up with a such a document. 
Regards, Ceki



--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: cvs commit: jakarta-site/xdocs index.xml

2002-03-03 Thread Ceki Gülcü


-1

I disagree with this change because it gives the impression that
LogKit is a top level jakarta project which is not the case. The
addition is placed just to log4j giving the impression that the two
packages have equal footing. This misleads the users to think there
are two logging packages sanctioned by the Jakarta project.

I am undoing this change pending a decision by the PMC or any other
collective decision. Regards, Ceki

ps: I went away on vacation on the 23rd of February and came back just
today so I could not react earlier.

--
Here is Peter's original message from the 24th.

On 24 Feb 2002 08:38:13 - Peter Donald wrote:

donaldp 02/02/24 00:38:13

   Modified:docs index.html
xdocsindex.xml
   Log:
   Add LogKit blurb.

   Revision  ChangesPath
   1.62  +12 -0 jakarta-site/docs/index.html

   Index: index.html
   ===
   RCS file: /home/cvs/jakarta-site/docs/index.html,v
   retrieving revision 1.61
   retrieving revision 1.62
   diff -u -r1.61 -r1.62
   --- index.html   20 Feb 2002 03:52:05 -  1.61
   +++ index.html   24 Feb 2002 08:38:13 -  1.62
   @@ -308,6 +308,18 @@
tr
td bgcolor=#a0ddf0 colspan= rowspan= 
valign=top align=left
font color=#00 size=-1 face=arial,helvetica,sanserif
   +a href=./avalon/logkit/index.htmlLogKit/a:
   +/font
   +/td
   +td bgcolor=#a0ddf0 colspan= 
rowspan= valign=top align=left
   +font color=#00 size=-1 face=arial,helvetica,sanserif
   +A fast and well designed logging toolkit.
   +/font
   +/td
   +/tr
   +tr
   +td bgcolor=#a0ddf0 colspan= rowspan= 
valign=top align=left
   +font color=#00 size=-1 face=arial,helvetica,sanserif
a href=./oro/index.htmlORO/a:
/font
/td



   1.31  +4 -0  jakarta-site/xdocs/index.xml

   Index: index.xml
   ===
   RCS file: /home/cvs/jakarta-site/xdocs/index.xml,v
   retrieving revision 1.30
   retrieving revision 1.31
   diff -u -r1.30 -r1.31
   --- index.xml20 Feb 2002 03:52:08 -  1.30
   +++ index.xml24 Feb 2002 08:38:13 -  1.31
   @@ -106,6 +106,10 @@
td valign=topA fast and flexible logging library for Java./td
/tr
tr
   +td align=right valign=topa 
href=./avalon/logkit/index.htmlLogKit/a:/td
   +td valign=topA fast and well designed logging toolkit./td
   +/tr
   +tr
td align=right valign=topa href=./oro/index.htmlORO/a:/td
td valign=topSet of text-processing Java classes that provide Perl5 
compatible regular expressions, AWK-like regular expressions, glob 
expressions, and utility classes for performing substitutions, splits, 
filtering filenames, etc./td
/tr
   


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




version numbers in jars

2002-02-21 Thread Ceki Gülcü


The following is from http://www.ibiblio.org/java/#recent

I have a request to make of the log4j team, as well as all the other
Java programmers at the Apache Project, IBM alphaWorks, Sun, and
everyone else who distributes JAR archives. Could you please attach a
version number to all your JARs? I maintain several systems whose ext
directories I try to keep in sync. However, it's extremely difficult
to do this when there's no straight-forward way to look at log4j.jar
(or xercesImpl.jar, servlet.jar, jedit.jar, saxon.jar, or any of the
several dozen other jar archives I work with on a daily basis) and
quickly tell which version it holds. I personally experience this
problem mostly with XML related jars, but the problem is hardly unique
to XML. It's especially problematic when some other software requires
a particular version of a third-party jar. For instance, IBM
alphaWorks' XML Security Suite works with Xerces 2.0 beta 2 but not
earlier or later versions. The Apache XML Security project works with
the release version of Xalan 2.2 or later. My own XInclude software
works with Xerces 1.4.0 through 1.4.3 but not earlier or later
versions.

Mostly I just add numbers to the jar archives when I copy them into my
ext directory. However, that step is often forgotten, and it's almost
never been done when I'm working with somebody else's system
(e.g. trying to debug some student's homework for him or her). And
when a distribution like FOP bundles several third party jars like
Batik and the Bean Scripting Framework, they often don't bother to
tell you which version they've bundled. It would be much easier if all
JARs included appropriate version numbers in their names. It's also
important that JARs name themselves with their sources for JARs that
may come from multiple places. A good example of what to do is the
Bouncy Castle JCE implementation. It's called
bc-jce-jdk13-112.jar. You can tell at a glance that it's version
1.1.2 of the Bouncy Castle implementation of the Java Cryptography
Extension for Java 1.3. Even if that isn't obvious, you most certainly
won't confuse this with any other implementation of the JCE (of which
there are several).


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: Jakarta PMC Nomination - Rejection

2002-02-02 Thread Ceki Gülcü


Shit. You'll be sourly missed. I guess we could not expect you to be
the ugly duckling for ever. 

Best of luck with your new project. No doubt you'll do well.

At 12:19 01.02.2002 -0800, you wrote:
Hey all,

I just wanted to say that I'm not going to accept my Jakarta PMC nomination
and do not want to be included in the voting for the next election.

I have been involved with Java Apache/Jakarta since Sept 1996 and I think
that it is time for me to move on from being politically responsible for
this group. Honestly, I'm jaded and burned out on it all.

That said, I recently signed a 10 year lease on a prime event space in
downtown San Francisco and I am moving towards spending more time being a
big time night club owner than working on Jakarta. More info:
http://www.studioz.tv/ (p.s. that site is built with Anakia smile)

I also just released Scarab 1.0b1 and am focused primarily on making Scarab
the best issue tracking tool around. Expect to see more great developments
on this project. It is by far, one of the best designed, largest and most
complex pieces of software that I have ever had the pleasure of helping
develop. It will be around for a very long time and will eventually put
Bugzilla out of business. More info: http://scarab.tigris.org/

thanks,

-jon


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

--
Ceki Gülcü



--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: [PROPOSAL] POI @ Jakarta

2002-01-17 Thread Ceki Gülcü

At 14:45 17.01.2002 -0500, Andrew C. Oliver wrote:
Proposal for POI - A Jakarta Subproject 
version 1.0 - 17 Jan 2002 

(0) rationale 

The POI project seeks to provide pure Java APIs for reading, creating 
and manipulating files written in formats based on Microsoft OLE 2 
Compound Document Format.  The POI project has already successfully 
created a Pure Java OLE 2 Compound Document Format library (POIFS) and a
port of the Microsoft Excel '97(-2002) file format (aka XLS, BIFF8) and 
tools for serializing XML in these formats (which will be hosted as part
of Cocoon 2). 

The POI project user community is growing leaps and bounds in usage as 
evidenced by its position as one of the most active projects on 
SourceForge and the 2,290 people who have downloaded it so far this 
month.  The POI project currently has two active developers.  The 
development community  might be small but is fanatically committed (and 
growing rather  quickly).  It is likely that the upcoming port of the  
Microsoft Word 97 File format will increase the size of the development 
community, not to mention the user community.  The documentation is 
comprehensive and includes full documentation on the previously 
undocumented (or at least incompletely documented) Microsoft OLE 2 
Compound Document Format. There are also HOW-TO documents that 
illustrate use cases and examples. Lastly, The project founders have 
agreed to collaborate with a developer at the OpenOffice.org project on 
the Excel File Format Documentation. 

Many Jakarta projects could potentially take advantage of POI and its 
use in Jakarta will likely further seed the POI developer community. 
POI is a unique project in the Java world.  Up until now there have been
no successful free attempts to provide read/write access to OLE 2 CDF or
MS Excel (97+) file formats. POI coupled with other Jakarta technologies
could produce some highly useful offspring.  A few specific examples 
might be Office Document indexing for Lucene, Velocity generating Excel 
and Word document presentations, Office document management capabilities
for Slide as well as content delivery and editing in Turbine. 

Hi Andrew,

Have you asked the Lucene people whether they were interested in using
POI? Is the slide community interested? 

In addition, I don't see how a templating engine like Velocity could
use POI, but again I am not an expert on the topic.


--
Ceki Gülcü - http://qos.ch



--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: [PROPOSAL] Jakarta PMC bylaws change

2002-01-16 Thread Ceki Gülcü


+1

At 14:27 16.01.2002 -0500, you wrote:
The number of PMC seats will be set at seven.  Annually, all seven seats
will be up for renewal.  The ASF board will be asked to provide a person or
persons to administer the nominations and a subsequent ballot. The
administrator(s) will determine the mechanics of the voting procedures.
Any committer to any Jakarta code base will be eligible to vote.  Once the
new PMC is in place, the first order of business will be to determine a
chairperson from amongst their ranks.

Once ratified, this proposal would be effective immediately, and an
election would be initiated.

- Sam Ruby




--
Ceki Gülcü - http://qos.ch



--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: License change for new year ?

2002-01-09 Thread Ceki Gülcü


Geir,

I think the rule is so obvious once stated that no one is likely to disagree with it. 
In a perfect world, we would vote on such a rule in order to adopt it formally. 
However, we don't live in a perfect world with unlimited resources and the Jakarta 
tradition of lazy approval seems to apply. Regards, Ceki
 
At 20:24 09.01.2002 -0500, Geir Magnusson Jr. wrote:
On 1/9/02 12:53 PM, Jon Scott Stevens [EMAIL PROTECTED] wrote:

 on 1/9/02 6:49 AM, Sam Ruby [EMAIL PROTECTED] wrote:
 
 Ted Husted wrote:
 
 I think on a continuing basis, Committers should update the copyright
 notice to include the current year whenever they update a source file.
 This will happen most often in the early part of a year, but should
 happen year-round. So, as Peter said, if you revise a source file from
 1999, you should change the copyright notice in the license to read
 1999, 2002. If the file was from 2001, we would change it to 2001-2002.
 
 I have never bothered to learn the details (there are some topics I avoid
 lest I become perceived as an expert on the subject ;-)), but when working
 on software for my employer (who has a tendency of being careful about such
 things), we tend to follow the roughly the rules specified above.
 
 Hey Ted, can you update source.xml (or whatever appropriate jakarta-site2
 file) in order to get that little rule 'documented'?
 

Here's a quick question - what makes that a rule?  Ted putting it into a
file?

I don't disagree with the  suggestion - I mean, we need to do it - I am just
asking what makes it a rule now


On the issue itself, isn't this something that should be uniformly done
across all Apache projects?

I would think that since it's part of the License, we want uniformity.

-- 
Geir Magnusson Jr.   [EMAIL PROTECTED]
System and Software Consulting
You're going to end up getting pissed at your software
anyway, so you might as well not pay for it. Try Open Source.



--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

--
Ceki Gülcü - http://qos.ch



--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: License change for new year ?

2002-01-09 Thread Ceki Gülcü



I am not a lawyer and the following is yet another one of my heretical POVs.

Legally speaking the copyright notice is not even required in each source file as long 
as the whole work can be unequivocally attributed to their rightful owners through 
other means.

Example 1) In my home I don't have my name written on every item and piece of 
furniture. There is a littler sign on the door that says this is my home. It follows 
that everything contained therein is my property. 

Example 2) If you look inside any book, you are likely to find that there is only one 
copyright notice covering the whole book. You are very unlikely to find another 
copyright in no sentence, no paragraph, nor in any section not even in any chapter. 
You will find one copyright section inside the cover page. 

Copyright law applies the same way to software as to books. 

Tearing out a page from a book does not remove the copyright of the author even if 
there is no copyright notice on the torn out page. Think about it for a second.

Why are putting copyright notices in every source code file? Because we can and it is 
admitted by industry practice, not because we have to. 


At 22:29 09.01.2002 -0500, Ted Husted wrote:
At this time, the so-called short form should not be used. Although we
are told that it is legally defensible. 

http://nagoya.apache.org:8080/jyve-faq/Turbine/screen/DisplayQuestionAnswer/action/SetAll/project_id/2/faq_id/38/topic_id/205/question_id/787

The ASF chair has made a posting to the Committers list regarding a new
license, which will support a short form, but approval is still
forthcoming. 

-Ted.


Andrew C. Oliver wrote:
 
 Pete,
 
 Just a question.  Maybe I missed this in the discussions.  Every once
 and a while the short license versus big license discussion goes
 through here.  Meaning the source code for some projects whether
 correctly or incorrectly be convention uses a statement and short
 reference to the license and others post the license in its entirety.
 Did anyone consult those licensing folks to check if there was a legal
 reasoning?  While I have no particular passion on this and don't wish to
 see a war here, I do know some projects use one and others use another
 and I'm just curious if there are any legal problems that could result.
 
 (at POI we use the long form convention because it seems to be in line
 with where the discussion leaned on here and I'm a paranoid type person)
 
 Thanks,
 
 Andy
 --
 www.superlinksoftware.com
 www.sourceforge.net/projects/poi - port of Excel format to java
 http://developer.java.sun.com/developer/bugParade/bugs/4487555.html
 - fix java generics!
 
 The avalanche has already started. It is too late for the pebbles to
 vote.
 -Ambassador Kosh
 
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]

-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Building Java web applications with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

--
Ceki Gülcü - http://qos.ch



--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: Volunteer Wanted

2002-01-08 Thread Ceki Gülcü


First, the page is outdated, Java Apache is not Jakarta. Second, acting as a 
receptionist at desk with a million visitors a day is not what I call a dream job. The 
task should left to one person but shared on a rotational basis. 

I am willing to be the first and take over for *one* month. Any other volunteers? 
Regards, Ceki

At 14:57 08.01.2002 -0500, you wrote:
I'd say it should be the [EMAIL PROTECTED] 

and if anyone, including Paulo, want to help out with the Webmaster
emails, that would be great.

Jon Scott Stevens wrote:
 
 I want to remove my name from this page:
 
 http://www.apache.org/foundation/preFAQ.html
 
 I nominate Paulo to put his name there instead so that he can start
 contributing more than just being a pain in my ass. Is that cool?
 
 -jon
 
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]

-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Building Java web applications with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

--
Ceki Gülcü - http://qos.ch



--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: Questions

2002-01-07 Thread Ceki Gülcü


Look, I think Sam is irreplaceable and so are you.  I don't want to even think about 
what would happen if anything happened to any of you. Heaven forbid. That's all I have 
to say on this. 

At 11:27 07.01.2002 -0800, Jon Stevens wrote:
If Sam gets hit by a bus tomorrow, who would be willing to step up and take
over the PMC chairmanship?


p.s. I have no interest in being PMC Chair.

-jon

-- 
Standard rules apply: Ask any questions, and you get the job. ;-)

(I left this .sig in on purpose, because this quote is from Sam and I think
it is funny based on the question.)

--
Ceki Gülcü - http://qos.ch



--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: crushed

2002-01-07 Thread Ceki Gülcü

At 13:11 07.01.2002 -0800, Jon Scott Stevens wrote:
on 1/7/02 12:44 PM, Andrew C. Oliver [EMAIL PROTECTED] wrote:

 I think many folks on
 the list aren't listening to each other let alone to someone from the
 outer circle.  

That is my complaint about not just this list, but the entire project. We
have people like Ted and Craig who are perfectly happy just sitting in their
bubble sub-projects and doing whatever they want and you have people like
myself who see a larger picture of what Jakarta is (or could be) and want to
see people work together more and create less duplication of exactly the
same functionality. Yes, that statement is based on their previous postings.

 Its funny I kind of agree with some (but not all) of the points that Jon
 guy makes but he seems to want to make them in such a way that they are
 divisive instead of providing the leadership Stefano praises him for.
 Leadership is taking the boat and sailing it and inviting others to come
 along not sitting in the back complaining about the heading or
 proclaiming its just going to sink and the hell with you all maybe I'll
 quit.  I hope he sees this and becomes the guy Stefano says he is.

The problem is that I feel like the boat has already capsized, sank and
rotted on the ocean floor. At this point, I'm pretty disheartened about
Jakarta...more so than I have felt in over 6 years of being here. I have no
other way to express my unhappiness than to express it by saying it. I feel
like I can't change things anymore and about the only person who could is
Sam, but I am not seeing him take the reigns in such a way to rebuild the
ship...only to try to a lifeboat together over the next few years...

If you look at how Scarab is run, we are pretty damn successful at this
point with regards to building and managing a strong developer community
around it. And it isn't even a Jakarta project. I personally see the model I
have used for Scarab as pretty close to right way to run projects.

Not that it is a contest, but I can guarantee I feel more crushed than you.

Have many developers does scarab have, 10? Jakarta has around 200 committers plus ten 
times that many developers. At 200'000 USD per committer that's a budget of 40'000'000 
USD a year. I'd estimate the budget of an equivalently sized software company at 
100'000'000 USD year. You think that's easy to manage? Sam's vision differs from yours 
and mine. That does not mean he is wrong and that you are right.  Anyway, what is 
exactly your vision? and how would you go about getting there? (How can you force 
people to cooperate more?)

How many places do you know where people keep arguing and arguing and still stick 
around? The only other place I know is my family. 

--

Ceki Gülcü - http://qos.ch



--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: Cultural homogeneity

2002-01-06 Thread Ceki Gülcü

At 10:29 06.01.2002 -0500, you wrote:
Ted Husted wrote:
 (1) That we petition the ASF to change our charter and remove the word
 server, so what we are simply charged with providing production
 quality solutions on the Java platform.
 
 [I'd link to our charter, but can't find the ASF minutes any more, and
 don't know where else it was published.]

Found our copy at least -- 

http://jakarta.apache.org/site/pmc/01-03-19-meeting-summary.html

at 2.1

So I'm thinking we might propose that our charter be amended to 

RESOLVED, that the Jakarta Project Management Committee be and
hereby is responsible for the creation and maintenance of
-1  commercial-quality, open-source, server-side solutions for the Java
+1  commercial-quality, open-source solutions for the Java
Platform based on software licensed to the Foundation; and be it
further

Some of the existing projects within Jakarta are server-side only, others are 
client-side as well as server-side, none are client-side only. Removing the 
server-side restriction would allow strictly client side applications such as word 
processors, editors, spread sheet programs, etc. into jakarta. 

Rewording of the charter is perhaps appropriate but completely removing the 
server-side restriction is not. I consequently vote -1 on the proposed change. 


So that Ant, BCEL, and whatever would no longer be out of scope, and we
could also consider client-side Java packages when they are proposed. 

Would you care to propose a different wording? 


--
Ceki Gülcü - http://qos.ch



--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: Cultural homogeneity

2002-01-06 Thread Ceki Gülcü

At 03:35 07.01.2002 +1100, you wrote:
On Mon, 7 Jan 2002 03:08, Ceki Gülcü wrote:
 Some of the existing projects within Jakarta are server-side only, others
 are client-side as well as server-side, none are client-side only. 

except for JMeter ?

Well, JMeter is a client application to test the performance of a web server. It can't 
do anything else but test a server. So imho it's more server-side than many other 
projects we currently have. 

Server-side software in the case of Jakarta means software that is commonly executed 
by servers, most notably within servlet containers. This may include software that 
runs on the client but excludes software that runs *only* on client.

So, the word server-side might require some further clarification, but removing it 
completely is not just a cosmetic change. It means opening the flood-gates. 


--
Ceki Gülcü - http://qos.ch



--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: On unity and coherence [was Re: [Request For Comment] POI @ apache]

2002-01-05 Thread Ceki Gülcü

At 15:31 05.01.2002 +0100, Stefano Mazzocchi wrote:
[Snip]


In my mind, all this long trail of thoughs yields the following
equation:

 metacommunity size * community coherence * individual freedom = constant

This equation is misleading. Coherence and individual freedom are 
not inversely proportional, perhaps related but not inversely 
proportional. That much is certain. 
  
in result, if we unify the two projects, we double the size of the
metacommunity and we must pay the price of decreased coherence and/or
decreased individual freedom.

But are we sure the pros outweight the cons?

No, we can't be sure. The experiment cannot be undone and started
over. 

Anyway, contrary to my previous hints, I am unsure if having XML and
Jakarta would benefit either Jakarta or XML. If someone cares enough
about a particular XML project nothing keeps him/her from participating 
in that project.

IMHO, XML does not and will never have a community as long as two of
its most important projects directly compete with each other. The
success of one is related with the failure of the other. XML
Community? Won't happen in a million years. How the did Crimson
become an Apache project anyway?

Unity and coherence (the subject of this thread) are strongly related to
management and decision making. Since we don't have a manager, we must
have a healthy decision making process.

The current system of voting where each participant is granted veto
power is a system geared towards non-decision making. This was perhaps
one of the intentions of the founders of the ASF. Anyone know where -1
tradition came from?

My suggestion is institute a new tradition where members of the
community can make proposals which the community votes on.

Advantages: decisions can be made.
Disadvantages: decisions can be made.

The required majority for the adoption of proposals can be simple or
qualified. Even if the qualified majority is 3/4, this would be better
than the veto system we have today. Although a veto can be overridden
by a 3/4 majority, as far as I know, this has never happened in the
past.  Today someone voting -1 means end of discussion. 

I dare anyone to -1 that. Regards, Ceki


--
Ceki Gülcü - http://qos.ch



--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: On unity and coherence [was Re: [Request For Comment] POI @ apache]

2002-01-05 Thread Ceki Gülcü


Chris,

I think you are confusing project categorization with project community. These things
are very much unrelated. Regards, Ceki

At 23:44 05.01.2002 +0100, you wrote:
Hello,
Each structure has a cost depending on his level of organization. I think
there is today to many project in the jakarta and the xml project. I feel
confuse about finding the right information at the right place. And I think
it's high time to merge xml and jakarta.
The way java is organizing code in package is rather simple and efficient,
maybe organizing project this way is the solution.
We should debate about this organization.
I propose some package organization :

XML(Xerces,Crimson)
XSL(Xalan,FOP)
SVG(Batik)
WebApps(Cocoon, JetSpeed...)
JSP (TagLibs)
FrameWork(Turbine, Avalon, Struts..)
Project Management (Ant, Slide)
Metric  Testing (Log4J, WatchDog)
ToolBox(ORO, RegExp, Lucene)
...
I'd like your opinion about it, which package with which existing project.

Ciao
Chris
-
agitateur depuis toujours
***


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

--
Ceki Gülcü - http://qos.ch



--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: On unity and coherence [was Re: [Request For Comment] POI @ apache]

2002-01-05 Thread Ceki Gülcü

At 18:02 05.01.2002 -0500, you wrote:
Ceki Gülcü wrote:

 IMHO, XML does not and will never have a community as long as two of
 its most important projects directly compete with each other. The
 success of one is related with the failure of the other. XML
 Community? Won't happen in a million years. How the did Crimson
 become an Apache project anyway?

Look closely, Xerces 2 is the designated successor to *both* Xerces 1 and
Crimson.  The developers *are* working together.  I won't pretend that
everything is 100% smooth sailing, but significant progress is being made.

Point well taken.

 The required majority for the adoption of proposals can be simple or
 qualified. Even if the qualified majority is 3/4, this would be better
 than the veto system we have today. Although a veto can be overridden
 by a 3/4 majority, as far as I know, this has never happened in the
 past.  Today someone voting -1 means end of discussion.

 I dare anyone to -1 that. Regards, Ceki

The rules you describe don't look familiar to me.  The ones I am familiar
with are:

http://jakarta.apache.org/site/decisions.html
http://jakarta.apache.org/site/management.html

My mistake. I was always under the impression that new project creation
required a 3/4 vote *and* no binding vetoes (which I admit makes no sense).
Thanks for the clarification. Ceki



--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: Code conventions

2002-01-04 Thread Ceki Gülcü


On Wed, 02 Jan 2002 06:03:43 -0800, Sam Ruby wrote:
 Let's all take a moment to review:

   http://www.godwinslaw.com/

Amusing but not very pertinent to the discussion.  No one exchanged
accusations of Nazism. Although I recognize that your goal was
probably to diffuse the tension.

As things stand today, the Jakarta project is a loose assembly of
subprojects united by a common license, a common web site and a common PMC. 

Here is what http://jakarta.apache.org/site/roles.html has to say on
the Project Management Committee (PMC):

   This committee is the official managing body of the Jakarta Project
   and is responsible for setting overall project direction.

The PMC currently follows a non-interventionist policy. Its actions in
the past year have been limited to accepting or rejecting new
subprojects which is inadequate for setting the overall project
direction, the stated goal of the PMC.

The inability of the PMC to take initiative stems from the Apache
voting process where every member has a veto power. This limits the
decision power of the PMC to consensual decisions only.

The Jakarta PMC is averse of discussing things in private in fear that
its legitimacy might be challenged.  IMHO, if the legitimacy of the
PMC is challenged, let the challenger wait and suffer until the next
PMC elections. I believe the next elections are scheduled for February
or March 2002.

The current system of veto based voting might be appropriate for
development but is inappropriate for managing large projects like
Jakarta. Either we admit it and act now or watch Jakarta become
SourceForge-elite, an assembly of excellent projects but with no
common purpose.

Jakarta does not have a benevolent dictator where the puck stops.
Recognizing this fact, we either:

1) Elect a PMC with real power, power to intervene and take painful
decisions, until the next elections.

2) Instate a system based on referendum, where the public can directly
intervene in making laws. By public, I mean developers with commit
rights.

To avoid voting on trivialities, a referendum would require the support of
at least five committers to acquire the valid status. After a
possible but short delay, a valid referendum is submitted to popular
vote. The result of the vote determines whether the referendum is
accepted or rejected. An accepted referendum becomes law of the land.

To avoid keeping voting on the same issue time and again, a wait
period of 12 months is necessary between two referenda on the same
or nearly the same issue.

3) Keeps things as they are and hope for the best.

Regards, Ceki


--
Ceki Gülcü - http://qos.ch



--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




RE: More abuse of coding styles...

2002-01-04 Thread Ceki Gülcü

At 10:44 04.01.2002 +, you wrote:
 -Original Message-
 From: Kief Morris [mailto:[EMAIL PROTECTED]]

 It is one of my major source of error when not using the '_'  and I
 have seen the error several times along with variable naming
 gymnastics to avoid the this. people would use aSomething or
   ^

 theSomething or whatever. That look crappy in the Javadoc.

 The standard way to handle this is of course:
[...]

See above. People will often forget to type 'this.' for the same reason they
forget to put braces around a single line statement: lazyness.

I think we all do this from time to time...human nature you know...

Stephane


People who repeatedly forget to type this represent a minority and
should perhaps look to exercise a different profession. The problem
with

public void setSomething(Object something){ 
  this.something = something; 
}

is 

public void setSomethingComplicated(Object sometingComplicateed){ 
  this.somethingComplicated = somethingComplicated;
}


--
Ceki Gülcü - http://qos.ch


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: More abuse of coding styles...

2002-01-04 Thread Ceki Gülcü


Hey Jon,

It is not amazing. It is normal. The paragraph that you quoted says:

  All Java Language source code in the repository must be written in
  conformance to the Code Conventions for the Java Programming Language
  as published by Sun. However, some projects may decide to override
  these defaults and use their own defined conventions. For example, the
  Turbine project has its own defined conventions which are similar to
  the Sun standards but specify slightly different conventions.

Which really reads: we have conventions but you are free to ignore
them -- what people have flocked to do gleefully..

Cheers, Ceki

At 17:54 03.01.2002 -0800, you wrote:
It is amazing to me...with all the discussion about coding styles and
following them, we still have people committing code that doesn't follow
what rules we do have...

on 1/3/02 11:00 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:

Re: cvs commit: jakarta-commons/logging/src/java/org/apache/commons/logging
SimpleLog.java

 +if(_showtime) {

http://java.sun.com/docs/codeconv/html/CodeConventions.doc8.html#367

Variable names should not start with underscore _ or dollar sign $
characters, even though both are allowed.

http://jakarta.apache.org/site/source.html

All Java Language source code in the repository must be written in
conformance to the Code Conventions for the Java Programming Language as
published by Sun.

-jon


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

--
Ceki Gülcü - http://qos.ch



--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: Code conventions

2002-01-04 Thread Ceki Gülcü

At 06:57 04.01.2002 -0500, you wrote:
On 1/4/02 6:43 AM, Ceki Gülcü [EMAIL PROTECTED] wrote:

 
 
 On Wed, 02 Jan 2002 06:03:43 -0800, Sam Ruby wrote:
 
 If some particular codebase under the Jakarta umbrella consistently
 chose to take actions which were inconsistent with the Apache mission,
 then I'm confident that the PMC would swiftly act to disolve this code
 base.  I am not aware of this being done before, so it would be
 uncharted territory, but I'm sure we would find a way.  And that way
 would not require 100% consensus.
 
 In my mind, the willful insertion of newlines in direct contradiction
 to the Code Conventions for the Java Programming Language does not
 rise to this level.
 
 This analysis sums up the current state of affairs. As long as you are
 in and do not commit murder, you are free to do whatever you like,
 regardless of the consequences of your actions. Murder is defined as
 not adopting or infringing on the Apache Software License.
 
 Is this how we want Jakarta to be? If not, what can be done?
 

I don't see what the negative consequences for community are when I do
something like

 if ( condition )
 { 
statement;
 }

versus

 if ( condition ) {
statement;
 }

or

  if ( condition )
  statement;

Other than I made my code is more readable :)
  
My question is what are the consequences to forcing me to do #2 when #1 is
perfectly acceptable throughout the professional world?  We are going to
look like a bunch of PHB's if we do this.  Someone's is then going to write
the utility JU (Jakarta Uglifier).

I realize that some of this is simply a matter of taste, and people don't
think that #1 above is more readable than #2. I'm just trying to figure out
why this personal style decision in what is in many ways an artistic
endevour constitutes a risk to the community.  Note that I don't advocate a
coding free for all - I also understand that with multiple developers, some
'workmanlike' ('workpersonlike'?) standards are important.


All excellent points. I don't have any good answers, just more
questions.

Yes, by imposing strict code conventions there is a real danger of
acting like a PHB.  Yes, code conventions infringe on artistic freedom
and might even curtail creativity.

The debate about code conventions is just an excuse to ask the
following question, and it is a question:

  Do we want to instate rules for the good of the larger community?

We keep saying that Jakarta is not SourceForge. How can this be if
each project can act totally independently? 

Aside : does Sun use deviation from coding standards as an actionable HR
issue?  ;)

On your resume, I see that you were terminated for cause at Sun?

Yes, I created too many classes with the opening brace on a separate
line...

Remember the scene where Lisa, from the Simpons, is thrown out of
music class even of she plays her sax beautifully. We all emphasize
with Lisa's view. However, what would you do if you were in the
teacher's shoes?

Questions, questions...


--
Ceki Gülcü - http://qos.ch



--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: Code conventions

2002-01-04 Thread Ceki Gülcü

At 08:01 04.01.2002 -0500, Geir Magnusson Jr. wrote:
 The debate about code conventions is just an excuse to ask the
 following question, and it is a question:
 
 Do we want to instate rules for the good of the larger community?
 

I think yes, but the prepositional phrase for the good of the larger
community is going to be the trouble spot...  Historically always has :)

 We keep saying that Jakarta is not SourceForge. How can this be if
 each project can act totally independently?

Because they really can't act *totally* independently, additional projects
can't be formed (and abandoned) ad hoc by 'outsiders', there is indeed peer
pressure (as well mechanical things like Gump) that enforce some
consistency, and lots of cross pollenation.  I mean, Jon is everywhere ;)

From my personal experience, I do think of it as one big community but
different 'departments'.  I talk to people from many of the subprojects when
I need something or have a question, and I certainly feel welcome and like
it's one big group.

That's a good description.

Another thought I have on this is that we are sort of like sourdough bread
made with a starter :)  We add new projects, but it's (usually) initiated,
championed and/or participated in by someone steeped in the Apache/Jakarta
'gestalt', so the traditions and practices continue.

The reasons for which projects get accepted or rejected is an important 
subject in itself.

 Remember the scene where Lisa, from the Simpons, is thrown out of
 music class even of she plays her sax beautifully. We all emphasize
 with Lisa's view. However, what would you do if you were in the
 teacher's shoes?

(I thought you were going to the scene : Lisa, get away from that Jazz
man! )

Oh, yes, then she (Maggie) turns to the to the Jazz man and says: 

Nothing personal, I just fear the unfamiliar.

How true, how succinct.

Well, that's the difference between the teacher having to do something about
it, and Principal Skinner listening in over the intercom and getting Lisa to
leave  Within the community, the community is the teacher, and can
legislate itself (modulo Principal Skinner, of course...)

Amusingly enough that episode starts with Bart writing on the chalkboard:

I will not instigate revolution! I will not instigate revolution!
I will not instigate revolution! I will not instigate revolution!
I will not instigate revolution! I will not instigate revolution!
I will not instigate revolution! I will not instigate revolution!
I will not instigate revolution! I will not instigate revolution!
I will not instigate revolution! I will not instigate revolution!
I will not instigate revolution! I will not instigate revolution!
I will not instigate revolution! I will not instigate revolution!

Regards, Bart.


--
Ceki Gülcü - http://qos.ch



--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: Code conventions

2002-01-04 Thread Ceki Gülcü

At 00:55 05.01.2002 +1100, you wrote:
On Fri, 4 Jan 2002 22:04, Ceki Gülcü wrote:
 1) Elect a PMC with real power, power to intervene and take painful
 decisions, until the next elections.

-1 power would be abused and misused. If power is what you want you are not 
going to get it by donning a skippy badge but earning it through respect. 

Power can and is abused. Knives can and do cut through flesh. Knives can 
also be used to cut bread. I have no problem delegating legislative power 
to the members of parliament as long as its members were elected for a 
limited length term in fair and square elections.

 2) Instate a system based on referendum, where the public can directly
 intervene in making laws. By public, I mean developers with commit
 rights.

yay - popularity contests! That would be sooo much fun.

Who is talking about popularity contest? What popularity contest?

 To avoid keeping voting on the same issue time and again, a wait
 period of 12 months is necessary between two referenda on the same
 or nearly the same issue.

And maybe we should elect a committee to determine whether issues are too 
similar and they can break apart into sub-committees to determine the 
viability of holding a referendum to determine if two issues are dissimilar 
enough that another referendum could be held for the issue.

Laugh all you want. Referenda are great. Ask any Swiss citizen. 

 3) Keeps things as they are and hope for the best.

things as they are are for the best. People do things because they see that 
it is the right thing to do for them - which usually means it is 
technically the right thing. Sometimes it takes time (it took me 1.5 years to 
convince one apache person of something) but most things work out better in 
the end. 

At times it is infuriating when someone else is doing something stupid but 
forcing them to change is not the answer - for one you may be wrong, if not 
you are probably going to cause resentment - not something healthy for the 
community.

I really don't like paying taxes but I do. I would be great to live in 
the Bahamas, drink cocktails and fornicate day in day out.


--
Ceki Gülcü - http://qos.ch



--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: Code conventions

2002-01-04 Thread Ceki Gülcü

At 00:57 05.01.2002 +1100, you wrote:
On Fri, 4 Jan 2002 23:23, Ceki Gülcü wrote:
 The threat is to Jakarta's *nature* and it comes from our indecisiveness.

 Real problems I see is

 1) lack of focus,

Dont see this as a problem. Each project is usually focused on its dowmain 
and the overall project has a sort of scope. Personally I would have no 
problem widening scope of jakarta to include virtually any java project, 
serverside, clientside, frameworks, products, etc but not everyone thinks 
this is a great idea ;)

No, some people would not like to see Jakarta widen its scope and 
they would -1 any steps in that direction.  However, it is certainly 
possible that a majority of Jakarta committers would be amenable to 
the idea.  

In the system I am suggesting, you would propose the idea, have four 
other committers support it, and then launch a vote on the subject. If it
were adopted then the scope of Jakarta would be widened and nobody would
be able to do anything about it, not me, not Ted, not even Jon.

Widening the scope of Jakarta is not necessarily a bad idea. Your ideas are 
not all bad. (Don't get me wrong, there are not always good either.)

 2) duplication between projects,

diversity aids evolution though preferably it would be intra rather than 
inter project duplicity. However the PMC has historically not seen that as 
desirable due to advertising. 

duplicity - noun, plural duplicities

1. a. Deliberate deceptiveness in behavior or speech. b. An instance
of deliberate deceptiveness; double-dealing.

2. The quality or state of being twofold or double.

I have read and reread your comment. It just does not make any sense. 

 3) lack of common procedures for doing things.

This is the one possible issue I see. However I only see it as a problem for 
the external interface between projects. Mainly this involves things like 
release naming cconventions, targets in ant files, location of intermediate 
and destination files in a build. 

It really is irrelevent to outsiders what indent style is used, whether 
anakia or stylebook is used yadda yadda.

So I +1 on suggesting standards for external parts of project, -1 for forcing 
it

Indeed, that seems to be the consensus.


--
Ceki Gülcü - http://qos.ch



--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: Code conventions

2002-01-04 Thread Ceki Gülcü

At 10:32 04.01.2002 -0500, you wrote:
For reasons that are unknown to me, none of the e-mail that I have sent
over the last few days has made it out to the mailing lists.  For all I
know, at some point in the distant future, it will all be unleashed and
make little sense out of context.  :-(

Anyway, it looks like e-mail that I send now gets through so let me take
advantage of it while I can...

Ceki Gülcü wrote:

 If some particular codebase under the Jakarta umbrella consistently
 chose to take actions which were inconsistent with the Apache mission,
 then I'm confident that the PMC would swiftly act to disolve this code
 base.  I am not aware of this being done before, so it would be
 uncharted territory, but I'm sure we would find a way.  And that way
 would not require 100% consensus.

 In my mind, the willful insertion of newlines in direct contradiction
 to the Code Conventions for the Java Programming Language does not
 rise to this level.

 This analysis sums up the current state of affairs. As long as you are
 in and do not commit murder, you are free to do whatever you like,
 regardless of the consequences of your actions. Murder is defined as
 not adopting or infringing on the Apache Software License.

All I am saying is that adopting a different set of coding conventions
should not be a federal crime.  

I totally agree.

Jakarta effectively is a federation of states, each with the power to 
adopt their own conventions.  I do have
great sympathy for Jon's point that those subprojects that have not taken
the time or effort to document their standards do a great disservice to
themselves and us all.

Ditto.

 Real problems I see is

 1) lack of focus,
 2) duplication between projects,
 3) lack of common procedures for doing things.

Let me start with #2.

Did you realize that the Tomcat project can service HTTP requests?  Gasp!
Lets get them to rip this code out as Apache has a little known HTTPD
project which owns this mission.

Not.

I see where you are heading.

This instance of duplication of effort is well known and essentially
sanctioned by the board.  Allowing people to fork and pursue their own
vision is part of the essence what makes open source different then the
centrally planned economies that one often finds in big corporate software
development projects.

Well put. 

Re: focus.  What do ant and httpd have in common?  The purpose of Apache is
not to build a single product or family of products.  The purpose is to
propagate an open methodology centered around community base development.
Quality or integration or unity of purpose are often useful by-products,
but not the central goal.

Couldn't agree more.

Re: lack of common procedures.  I will grant you that this is an area that
we can always improve on.  You have made a number of references to a
benevolent dictator implying that the existence of such would be an
improvement over the current state of affairs.  If that is the case, then I
am not that person.  I prefer to educate or cajole or nag over dictating.
Gump is a prime example.  (Note: in the case of a federal crime mentioned
above, I would not hesitate to initiate action to remove a committer or
even an entire code base).

Gump is a prime example indeed. Masterfully done.

As an example related back to this subject line, I would not be in favor of
a tool which rejects commits that don't conform to a particular style.  I
also would not be in favor of a tool which post-processes commits to
retrofit a particular style.  I would be in favor of a tool which reviews
commits and informs you of issues that it determines.  At the moment, Jon
serves this purpose.  ;-)

 I will not instigate revolution! I will not instigate revolution!

Be forewarned that the Apache tradition is to allow people with enough
fire in their belly to tackle a particular problem that is important to
them the freedom to do so.  If the problems you see are something that you
feel need tackling and the only effective way in which this can be
accomplished is for you to become the Jakarta PMC chair, then I could
certainly arrange for an election to take place.  I can't guarantee the
results of the election or the success of your quest, but I can do my part
to enable you to pursue your goals.

Think about this for a while, and let me know if this is a path you wish to
pursue.

I have thought about for about 30 seconds and the answer is no, non, 
nein, nyet. Thanks, but no thanks. You don't want me as chairman. 
Trust me. I hope that was clear enough to dispel any misconceptions. 
If not, I'll be sure to repeat it again the next time the question comes
up.

We have been  lucky to have you serve as PMC chair.  I do not 
wish to offend anyone but  I can't think of anyone else better 
qualified than Sam. If I were to draw list of preferences for chair
my name would not be second after Sam, not the third, not the fourth...  

Coming back to your point of the propagation of an open methodology centered 
around

Re: Jakarta Status [was Code conventions]

2002-01-04 Thread Ceki Gülcü

At 11:34 04.01.2002 -0500, you wrote:
Ted Husted wrote:

 What would also help, I think, would be if we published more of our
 statistics. I know Vincent was working on a download stats page once.
 I've also seen people post interesting statistics about the posts to the
 mailing lists. A snapshot of how many commits are being made and number
 of unique committers making them would also be interesting. And other
 things, I'm sure.

 Now, if I only had the faintest idea of how to automate something like
 this ...

Stefano, I and others are working on this.

http://marc.theaimsgroup.com/?l=xml-apache-generalm=100857962129228w=2
http://www.apache.org/~stefano/forrest/1.5/

- Sam Ruby

P.S.  Food for thought: wouldn't it be nice if we could somehow merge xml
and Jakarta?  Then discussions as to where POI should go would be moot.
Gump doesn't care about these arbitrary distinctions, why should we?

+1 on the principle of merging Jakarta and XML. However, you realize
there are technical considerations such as the look and fell of the
merged web-site. More importantly, what would be the scope of the merged 
XML+Jakarta?

How should we call the combined project? ApacheGrabBag? SourceForgeII?

How about all the C++ projects in XML land? 

When do you think ApacheGrabBag/SourceForgeII and the httpd projects 
could be merged?

Seriously, I think the idea is worth our consideration. Regards, Ceki


--
Ceki Gülcü - http://qos.ch



--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




RE: Code conventions

2002-01-04 Thread Ceki Gülcü


Gerhard,

Is it fair and accurate to say that he came to power 
within the bounds and rules of a democratic system? 

At 17:58 04.01.2002 +0100, you wrote:
Hi,

skip/

Any democratic system is imperfect and hence flawed. Hitler was elected
democratically although he soon moved to dismantle the system that
brought him to power. D'oh, that damn Godwin's Law!

Nein ;), Hitler and his NSDAP gets only ~30%. He became Reichskanzler
because the other so called democratic parties like Volkspartei and
Socialist where so quarreled that they were unable to form a strong
coalition to kick this asshole out and preserve my country from this
dark 15 years.
Therefore the current Reichspräsident Hindenburg called Hitler for the
new Reichskanzler, because the existing Parlament was to weak. After
his dead '35 Hitler began with the so called Gleichschaltung.

Hitler slowly destroyed the democratic system, but he was *never* elected
democratic!!

skip/

  Gerhard




--
Black holes were created when God divided by zero.
--




--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

--
Ceki Gülcü - http://qos.ch



--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: More abuse of coding styles...

2002-01-04 Thread Ceki Gülcü

At 10:35 04.01.2002 -0800, you wrote:
on 1/4/02 3:28 AM, Ceki Gülcü [EMAIL PROTECTED] wrote:

 All Java Language source code in the repository must be written in
 conformance to the Code Conventions for the Java Programming Language
 as published by Sun. However, some projects may decide to override
 these defaults and use their own defined conventions. For example, the
 Turbine project has its own defined conventions which are similar to
 the Sun standards but specify slightly different conventions.
 
 Which really reads: we have conventions but you are free to ignore
 them -- what people have flocked to do gleefully..
 
 Cheers, Ceki

Keyword above: 'defined'

Fine distinction. Keyword: fine (pun intended).


--
Ceki Gülcü - http://qos.ch



--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: [PROPOSAL] New Project Creation Guidelines

2001-10-18 Thread Ceki Gülcü


You should remove the last paragraph, otherwise +1. 

At 21:31 17.10.2001 -0700, you wrote:
Here is my proposal for new project creation guidelines. I have not linked
it into the main site until I can get 3 +1 votes from the PMC and 0 -1 votes
from the PMC.

http://jakarta.apache.org/site/newproject.html

I will accept any patches against this document and/or direct commits from
PMC members.

:-)

-jon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

--
Ceki Gülcü - http://qos.ch
Link of the day: http://www.washingtonpost.com/wp-dyn/articles/A40473-2001Oct10.html


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: ASPizer

2001-10-18 Thread Ceki Gülcü

At 08:48 18.10.2001 +0200, you wrote:

| Put your project on SourceForget.net. There is another project there that is
| now hugely successful that we also rejected here and which I hosted for a
| number of years on my own dime, the Jboss project. Hope is not lost.

So you (Jakarta) rejected Jboss. I didn't know that. How incredibly smart
of you. Think about the synergies between Tomcat and Jboss!!! Wow!
Incredible.

and you think Jon is politically incorrect! Have you been on the 
JBoss lists?




--
Ceki Gülcü - http://qos.ch
Link of the day: http://www.washingtonpost.com/wp-dyn/articles/A40473-2001Oct10.html


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: ASPizer

2001-10-17 Thread Ceki Gülcü

At 22:21 17.10.2001 +0200, Endre Stølsvik wrote:
On Wed, 17 Oct 2001, Ceki Gulcu wrote:

|  As a coder, I've mentioned before, he's apparently very good. And his
|  observations and whatnot are also _insightful_, but nothing more.
|Why not just package things just a little bit nicer? Or just whatever?
|  Be a bit more polite? Be, you know, nice to people? Especially to people
|  he even doesn't know..
|
| I rather relate to a person who is direct than someone who always
| appears to be nice.

Jon's last post is just so very much better. Why not start with something
like that? It's still pretty direct, but in a much nicer, somewhat
diplomatic way.

I just cannot understand how you can justify such extreme rudeness!?

What extreme rudeness? Jon justifiably told Ranjit Mathew that Jakarta 
was not a dumping ground. He also outlined that unlikely promises were not 
good enough. While one may criticize his direct style, Jakarta is not a
popularity contest.

On the other hand, how do you qualify calling Jon an asshole? Unless you were
referring to the usefulness of that body part in evacuating shit, your name calling
constitutes extreme rudeness in itself.  Your subsequent comments were not 
much better either.

|  Jon is not doing Apache any good being like he is. I sincerly hope there
|  isn't any suits watching this list at all, because that could ruin
|  much..
|
| If you are trying to start a lynch party, you are unlikely to find
| many suitors in this forum.

I'm not. It's trying to point something out to Jon, actually. But he
definately does have a load of followers in this forum, protecting his 5
years earned rights to be rude. But I do know that there is several other
people that feel about the same way about Jon's behaviour on the lists he
subscribes to as me, tough. Just read the lists!

The only one being rude in this forum is you. Ceki


--
Ceki Gülcü - http://qos.ch
Link of the day: http://www.washingtonpost.com/wp-dyn/articles/A40473-2001Oct10.html


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: ASPizer

2001-10-17 Thread Ceki Gülcü

At 12:42 17.10.2001 -0700, Paul Ilechko wrote:
On Wed, 17 October 2001, Jon Stevens wrote:


 Let me point out that I tried tact the first time I responded:
 
  There is nothing in your proposal discussion WHY you would want to give this
  to the ASF other than because you think you have a cool product. Nor is
  there anything that suggests what the developer community is like (ie:
  people who would be working on the product) nor the user community and the
  people who would be responsible for supporting the user community.
 
 It didn't seem to get through to the guy so I brought it up a notch.
 
 -jon
 
Actually, I responded to all your points, then you decided it was time to insult us, 
at which point it no longer seemed worthwhile responding to you at all. Fortunately, 
not everyone on the list has the same attitude problem. 

I am sorry but what insult are you referring to? Disagreement != insult.


--
Ceki Gülcü - http://qos.ch
Link of the day: http://www.washingtonpost.com/wp-dyn/articles/A40473-2001Oct10.html


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: Apache logs problem

2001-10-01 Thread Ceki Gülcü


Hello Vincent,

At 13:57 01.10.2001 +0100, Vincent Massol wrote:
Thanks for the tip Ceki !

Most welcome.

* Yes, I am using the -p flag (incremental)

OK.

* I did not know about the -f one and just checked the man page. It seems
that by using it webalizer will process all logs from previous dates as if
had the time/date of the last known process log. Let's imagine a cron job
for day D : it will need to process D-1.gz (not too easy because we need to
consider when D is at the end of the month - but doable) and D.gz. For
D-1.gz, no -f flag should be used. For D.gz, I will need to use the D.gz
flag but then won't all logs accumulate for the time of the last entry in
D-1.gz, instead of the correct times at which these log happened ? Also, it
looks a bit complicated to me. It would seem normal that D.gz would contain
all logs for the D day  (as was happening before the past month). So, I
would prefer to correct that behaviour instead of trying to accomodate this
[unless someone tells me this behaviour is actually correct for such and
such reason].

Right, it's a pain. On the other hand, doesn't webalizer ignore out of order
entries? Due to out of order entries, your stats will not be 100% accurate 
but 99.95% should be good enough for our purposes...

* Do you know who is managing daedalus logs so that I can contact him and
solve this out ?

It's probably Brian but I do not know for sure. I am very curious about the reason 
behind the disordered log entires.

Thanks
-Vincent

- Original Message -
From: Ceki Gülcü [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, October 01, 2001 1:11 PM
Subject: Re: Apache logs problem



Hello Vincent,

Assuming you are using webalizer, have you tried using the -f (fold sequence
errors) and the -p (preserve state) flags?

Regards, Ceki

At 11:39 29.09.2001 +0100, Vincent Massol wrote:
It seems there is a problem of dates with the generated apache logs in
/x2/logarchive/www/2001

For example if you look at 2001/09/24.gz, the last entry is dated
25/Sep/2001:00:21:09 and the first entry of 2001/09/25.gz is dated
25/Sep/2001:00:00:04 !!

Now, even worse, I have tried to find in 24.gz the first entry that is in
25.gz with no success. It is not there ! It means there is a problem of
dates and the entries do not seem to be duplicate ... !??

This is a big problem for handling logs, especially for generating
statistics.

This problem is quite new (maybe 1 month at most) and it worked fine
before.

Can anyone help ?
Thanks

-Vincent Massol


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

--
Ceki Gülcü - http://qos.ch

The world owes Israel a great debt for destroying Saddam's
French built nuclear reactor in 1981 and thus preventing
nuclear blackmail in the region and perhaps beyond.
   -- Garry Kasparov (yes, the chess player)


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

--
Ceki Gülcü - http://qos.ch

The world owes Israel a great debt for destroying Saddam's 
French built nuclear reactor in 1981 and thus preventing
nuclear blackmail in the region and perhaps beyond.
   -- Garry Kasparov (yes, the chess player) 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: [VOTE] Making Commons-Cactus a top level projet

2001-09-18 Thread Ceki Gülcü


For whatever its worth, here is my +1. Sorry about the delay as I was away for a few 
days. Ceki

At 11:04 14.09.2001 -0400, you wrote:
Yes, Jason's vote came in after I posted. Counting Craig, that makes 8,
which is the threshhold. 

Jason and I (with assists from Sam and Brian) are just finishing up
Lucene, which could launch next week. 

I guess for Catcus all we need is a new CVS where Vincent can upload the
source. The Website and mailing lists are all ready in place. 

Should the +1's from the commons vote be the intial committer list,
Vincent? 

Commons Committers:

Morgan Delagrange, +1
Craig R. McClanahan, +1
Rodney Waldhoff, +1
Scott Sanders, +1
Geir Magnusson Jr., +1
James Strachan, +1
Vincent Massol, +1

We might also want to add a Who We Are page to the Cactus site listing
the Committers and other developers working on the product.

-Ted.


Pier Fumagalli wrote:
 
 Ted Husted [EMAIL PROTECTED] wrote:
 
  The votes have been flowing in on General, so you don't need to repost.
  It needs 8 votes to pass.
 
  +1 Peter Donald
  +1 Pier Fumagalli
  +1 Ted Husted
  __ Ceki Gulcu
  +1 Geir Magnusson
  +1 Craig McClanahan (from Commons vote)
  +1 Sam Ruby
  +1 Daniel Savarese
  __ Jon Stevens
  __ Jason van Zyl
 
 I've seen Jason V.Z. 's vote at 2:30 PM GMT on the general mailing list,
 and, if I'm not wrong, Ceki is on vacation?
 
 Pier

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

--
Ceki Gülcü - http://qos.ch


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: [OT] $un, M$ and Java

2001-08-13 Thread Ceki Gülcü

At 13:07 13.08.2001 -0700, Jon Stevens wrote:
on 8/13/01 10:54 AM, Kevin A. Burton [EMAIL PROTECTED] wrote:

 Send Stallman an e-mail right now.. [EMAIL PROTECTED]  He will tell you that Apache
 *is* Free Software.

No need to fill his inbox with crap.

http://www.gnu.org/licenses/license-list.html

 The Apache License, Version 1.1.
 This is a permissive non-copyleft free software license with a few
 requirements that render it incompatible with the GNU GPL.

Warning: The following horse has been probably beaten to death countless times. 

As far as I know, the incompatible requirements are the following:

 * 4. The names project-name and  Apache Software Foundation  must not be used to
 *endorse  or promote  products derived  from this  software without  prior
 *written permission. For written permission, please contact
 *[EMAIL PROTECTED]
 * 
 * 5. Products  derived from this software may not  be called Apache, nor may
 *Apache appear  in their name,  without prior written permission  of the
 *Apache Software Foundation.

If such is the case, the ASF could trademark Apache and the 4th and 5th requirements 
could be dropped. But [erhaps it is not possible to trademark the name of an Indian 
tribe. It seems to me that we are using copyright law to protect the Apache brand 
name, whereas trademark law could do just as well. I am sure the foundation has 
considered the alternatives and that there are very good reason for things to be the 
way they are. Regards, Ceki



--
Ceki Gülcü - http://qos.ch


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: Loggers, loggers, all over the place

2001-08-07 Thread Ceki Gülcü

Cedric,

If you think that j.u.l has all the features you need then you should
use it. Have you actually looked at the contents of j.u.l?

I lacks many useful features that people expect to find in a logging
package. Yes, even you will want them. Log4j might be obsolete five years
from now although that is far from certain. What is certain is that
j.u.l is obsolete today and will remain obsolete for the foreseeable
future.

If you can bind your code exclusively to JDK 1.4, then you are very
lucky. Most of us to not have that luxury. Regards, Ceki

At 15:46 07.08.2001 -0700, Cedric Berger wrote:
Avi Cherry wrote:

 What prevent the JavalinSoft class from working with the  JDK 1.4?
 And what prevent you from conditionally bridging the two package,
 *if you relly need to*?

 What's the benefit in settling on the 'standard' logging package if
 you end up having to include a copy of it (the JavalinSoft version)
 with every copy of your software?

I don't know if I really have to respond to that. This thread will never die.
But let me just try to tell a story:

Susan want to code against the JDK 1.4, because Susan don't want to
rewrite his application in 5 years, when most of the other logging
packages will be considered obsolete (I feel the flames coming).
So Susan want to code agains JDK 1.4 which is not yet really available.
but Susan is smart, she download the JavalinSoft and code against it.

2-3 years from now, when everybody is using at least JDK 1.4 (more
flames coming) Susan type perl -e s/com.javelin.logging/java.util.loging/g
and rm javelin.jar et voila, she has an up-to-date application!

I know there may be many reasons to chose, for example, Log4J,
no need to start another thread.
But there *is* also *many* good reasons to code against the JDK 1.4
API right now.

I also know I'm in ennemy territory here.

Cedric



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

--
Ceki Gülcü - http://qos.ch


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: Reply-to munging

2001-07-10 Thread Ceki Gülcü

At 21:11 10.07.2001 +0200, Gunnar Rønning wrote:
* Alex Chaffee [EMAIL PROTECTED] wrote:
|
| Can we turn off the munging of headers that is currently adding
| Reply-to on all the jakarta lists?

I agree with this, but this case has been up before with some people
having very strong feelings about the current config. I would prefer
to keep the reply-to header intact and rather teach people how to use
their mail programs.  Most people around ought to be able to that or is
the people here in Apache land not as bright as those in other userlands on
the net ?

I am for one thankful to Pier and others for the doing the ungrateful work of managing 
our mailing lists. As for the brightness of people in the Apache land, one can be sure 
that making allusions on our limited intelligence will bring out the best in us. Well, 
maybe not... Ceki

ps: I am also in favor of preserving the Reply-to field but people who have given the 
issue some thought have the opposite opinion. 

 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Licensing question

2001-07-03 Thread Ceki Gülcü


Hello,

We have a developer who would like to contribute a piece of code under the Apache 
software license but at the same time would like to keep using the same piece of code 
under a different (the original) license. I am sure this not the first time this 
happens. How did the foundation deal with the situation in the past? 

TIA, Ceki


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: Proposal to make BSF an ASF project

2001-06-25 Thread Ceki Gülcü


Somewhat late but still:

  +1

Regards, Ceki

At 00:23 23.06.2001 -0400, you wrote:
Pier P. Fumagalli wrote:
 
 Sam Ruby at [EMAIL PROTECTED] wrote:
 
  Craig R. McClanahan wrote:
 
  +1 for BSF as a Jakarta project.
 
  Ditto.
 
 Doh :) +1
 
 Pier

Re me

+1

geir

+1



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

--
Ceki Gülcü


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Reponse to my appeal

2001-06-14 Thread Ceki Gülcü


Greetings,

In just over 24 hours, over


--
Ceki Gülcü


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Response to appeal

2001-06-14 Thread Ceki Gülcü



Greetings,

In just 24 hours, over sixty individuals have responded with their
personalized request to Sun. Their requests as well as my critique of
JSR47 can be found at

  http://jakarta.apache.org/log4j/docs/critique.html

I am very happy about both the volume and quality of these requests
but I am sure we can do better. It is becoming increasingly evident
that no one will be happy about the upcoming logging API from Sun. I
invite you to join our community in protest against the pollution of
the Java environment with dubious APIs.

Thank you in advance, Ceki Gülcü


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: JSR47 Critique

2001-06-13 Thread Ceki Gülcü

At 10:58 13.06.2001 +1000, Peter Donald wrote:
At 01:37 AM 6/13/01 +0200, Ceki Gülcü wrote:

Greetings,

Here is a written critique of JSR47, the logging API shipped with 
JDK 1.4:

  http://jakarta.apache.org/log4j/docs/critique.html

If you agree with its contents, then you are encouraged to send a
personalized request to

I read the critique and while I agree with some of the points I am not sure
I agree with your reasoning. Specifically I don't think thing your analysis
of Parents vs Children is valid. I would actually say it is largely an
implementation detail ;)

Configutation order matters does suck tremendously but this is not due to
the JSR storage of children. 

Hello Peter,

For instance you say In log4j, changing the priority of a category
involves the change of a single field. Children categories dynamically
inherit the priority of their parent by traversing the hierarchy tree
upwards.. So in Log4j you climb *up* category tree every time log() is
called.

Compare this to LogKit which traverses *down* the tree when you set
priority/appenders. LogKit thus only accesses a logger local avariable
rather than traversing hierarchy tree each log request (thus is faster). 

Very interesting. I'll look at how you do it immediately.

So Parents vs Children has nothing to do with Configutation order
matters feature. I suspect parent access was blocked as it is a security
risk and a violation of patterns used in existing server products (which do
not condone *breaking out of the shell*).

Does not compute.

Also you state Unfortunately, in the JSR47 API, handlers cannot be
inherited because it would be prohibitively expensive (and unmanageable) to
let each logger to contain a Vector of all inherited handlers, especially
in large trees. which my experience would disagree with. 

Object references are relatively cheap (usually 4 or 6 bytes on intel
machines). It is rare that a logger has more than 4 appenders (only one
program I know of actually requires more than that). So in worst case you
end up with 16 (or 24) extra bytes per logger ... not a biggie - even in
embedded devices. (This is not dealing properly with additivity though
which would require extra storage).

Object references are cheap but new objects are not. You'd need a new Vector for each 
logger in the tree. Right?

The JSR does have a limited range of handlers and configuration methods
though.

If you agree with its contents, then you are encouraged to send a
personalized request to

  [EMAIL PROTECTED]

asking them to adopt log4j as the logging API shipped with JDK
1.4. Please cc: me if and when you choose do so. Thank you in advance.

From recent discussions with a Spec Lead for a core language/library
change, I would be very skeptical that this can ever occur. When making
changes to core java, the Spec Leads have to sign some heavyweight
contracts from the PMO. I am not sure if the Logging JSR is different as it
started out as a std extention but I suspect not.

I think it's a question of will in this particular case.

If you really want to improve the the logging JSR I would suggest you work
with them to point out changes to the spec that would be beneficial. You
may even be able to convert some of the log4j appenders to JSR47 handlers
and distribute as part of the JSR RI (though as it comes under the umbrella
JSR I am not su sure).

Absolutely but it takes two to tango... Ceki



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




  1   2   >