Re: [off topic] Zaurus PDA at java one

2002-03-27 Thread Geir Magnusson Jr.

On 3/26/02 6:32 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:

 
 Did anyone attending java one play with one ? Any good ? I am tempted to
 get one - but am held back by an experience with them a year ago or so
 when it barely worked - and would barf as soon as you did something
 serious on threading, garbage collection, etc.
 
 Dw


Dirk owns one now :)

-- 
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
They that can give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety. - Benjamin Franklin



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




Re: RegExp project still maintained?

2002-03-27 Thread Gunther Schadow

Mathieu Gervais wrote:

  I'm not sure if this is the place to ask for this, but I've noticed the
  regexp project seems to not be maintained anymore. [...] Is it
  recomended to switch to ORO? [...] I think if
  this project is going without any active maintainer it should be noted
  on the webpage and users should be guided to ORO instead.

I can't answer your question, but I might add that I have recently
evaluated (i.e., tried) the three alternatives of Java regex libraries,
Jakarta Regexp, GNU regex, and ORO and I was biased towards GNU regex.
But after the test I was convinced ORO was the best choice. It's most
general of the three (if a little more complicated to use) AND it
performed well (more efficiently than GNU regex.) So, I think ORO is
the best bet today.

regards,
-Gunther



-- 
Gunther Schadow, M.D., Ph.D.[EMAIL PROTECTED]
Medical Information Scientist  Regenstrief Institute for Health Care
Adjunct Assistant ProfessorIndiana University School of Medicine
tel:1(317)630-7960 http://aurora.regenstrief.org



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




Re: JakartaOne: The Gathering

2002-03-27 Thread @Basebeans.com

Subject: Re: JakartaOne: The Gathering
From: Vic Cekvenich [EMAIL PROTECTED]
 ===
I enjoyed meeting everyone, it was great fun. Thanks. Vic

Geir Magnusson Jr. wrote:

 On 3/25/02 10:40 AM, Jakarta General Newsgroup   (@Basebeans.com)
 [EMAIL PROTECTED] wrote:
 
 
Subject: Re: JakartaOne: The Gathering
From: Vic Cekvenich [EMAIL PROTECTED]
===
Can anyone come or do you have to be a Jakarta Comitter?

 
 Anyone and everyone.
 
 


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




Re: Keynote announcement

2002-03-27 Thread Geir Magnusson Jr.

On 3/26/02 6:09 PM, Marc Saegesser [EMAIL PROTECTED] wrote:

 I was at the Keynote and I must that I was really impressed both with the
 work you guys did behind the scenes to make this happend and with your
 presentation on the stage.
 
 You certainly didn't look nervice!


I was there too, and I agree - Jason, you came across as calm, cool and
collected

-- 
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
My inner cowboy needs to yodel.


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




Re: [off topic] Zaurus PDA at java one

2002-03-27 Thread dirkx



On Wed, 27 Mar 2002, Geir Magnusson Jr. wrote:

 On 3/26/02 6:32 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:

  Did anyone attending java one play with one ? Any good ? I am tempted to
  get one - but am held back by an experience with them a year ago or so
  when it barely worked - and would barf as soon as you did something
  serious on threading, garbage collection, etc.

 Dirk owns one now :)

Thanks to Geir :-)

Very cool and very niffty device - zillion times better than earlier
models. Just the fact that you can do 'apm' to see how full the battery is
:-) Any none with MacOS-X found out how to connect the USB - it seems the
be half recognized as a CDCD modem device - but not quite. Right now I
need to do a bit of three step route to get my classes onto the device for
running.

Dw


--
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 Waldhoff, Rodney

I'm quoting Ceki's entire message here because I think he raises a number of
interesting and valid points.

But I think this misinterprets what (in my mind) is the main point of
commons-logging.

One can use commons-logging, as you state, as a implementation-independent
logging wrapper in hopes of reducing the cost of  switching between log4j
and JDK 1.4 (or logkit or whatever else comes along). But as you say, for
some changes the switching cost is already quite low.  (It's not clear to me
that the switching cost between, say, logkit and log4j is similarly low, but
maybe it is, I really don't know.)

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.

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.)

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.

 - Rod

-Original Message-
From: Ceki Gülcü [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 26, 2002 10:11 PM
To: [EMAIL PROTECTED]
Subject: Comments on the commons-logging API



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 

Re: Comments on the commons-logging API

2002-03-27 Thread costinm

Ceki,

I'm not sure I understand very well this. 

I think we have a consensus on few items ( and you seem to just repeat 
them ):

- JDK1.4 logging is not useable as a 'standard logging API' ( even if it 
is released under JCP )

- log4j is the best logger ( for Peter and few others: logkit is the best 
logger, and I doubt too many people will argue that JDK1.4 logging is the 
best ). The consensus here is that everyone has a favorite logger 
implementation. 

- there are other logger implementations in use - JDK1.4, logkit, log4j, 
probably many others ( for example tomcat3.3 and tomcat4.0 each has a 
logger ).

- it is better for a user program to code using a single API and beeing 
able to choose the implemntation.

The commons-logging API is implementable by each logger, and it's the 
closest to a 'standard API for logging' that you can get. 

If the wrapping performance worries you - there's a very simple solution, 
at your disposal - just make log4j.Logger implement commons.Logger, 
create and maintain a log4j factory that is consistent with the rest of 
log4j and you'll have no wrapper :-)

With the current discovery mechnism, if you implement commons-logger 
factory and include the manifest entry in log4j, it'll automatically be 
used ( instead of the wrapper ). 

Replacing the package name is a silly sugestion - you realize most people 
want to release a single package and have it work, you can't ask the 
user to do a replace and recompile if they want a different logger.
 
The goal is not to be able to change the logger at compile time, but to be 
able to detect the platform logger and use it. The only way to do that is 
via a standard API - and commons-logging seems to be the only standard for 
logging that we have, supported ( mostly unwillingly :-) on all logging 
implementations. If you are concerned about the user experience with 
commons-logging and log4j, the best way to resolve that is by 
participating in commons-logging and implementing it in log4j so that 
log4j will work best with commons-logging.


Costin


On Wed, 27 Mar 2002, Ceki Gülcü wrote:

 
 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 

Request information for setting up a new CVS top level repository

2002-03-27 Thread Peter Carlson

Hi,

I am trying to find out what the policy or guidelines are for setting up a
new top level CVS repository.

I am a committer to the Jakarta-Lucene project and would like to setup
Jakarta-Lucene-Sandbox repository.

Who is the correct person to make this request to?

Thanks

--Peter


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




FW: Misspelling

2002-03-27 Thread Pier Fumagalli


-- Forwarded Message
From: Kennedy, Scott, MDCT Trenton [EMAIL PROTECTED]
Date: Wed, 27 Mar 2002 14:21:26 -0500
To: [EMAIL PROTECTED]
Subject: Misspelling



http://jakarta.apache.org/site/news.html#0327.1

release is misspelled as relase

Regards,
Scott


-- End of Forwarded Message


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




jakarta-site2 stylesheet makeover (was: RE: Printable pages)

2002-03-27 Thread Leo Simons

Taking the release early, release often advice to heart, I've
applied changes mentioned to the page at the url I posted earlier
and started work on the site.vsl file in jakarta-site2 (which
basically means cutting out a whole lot of stuff).

I've got no real previous experience with either the module or
velocity, so there might be 'some' mistakes :) Wasn't quite able
to figure out how to do testing. Someone wanna lend a hand?

cheers,

- Leo, short on time(tm)

 -Oorspronkelijk bericht-
 Van: Leo Simons [mailto:[EMAIL PROTECTED]]
 Verzonden: Sunday, March 24, 2002 10:00 PM
 Aan: Jakarta General List
 Onderwerp: RE: Printable pages
 
 
 Berin:
In that case, the entire Jakarta site needs to be redesigned.
It makes use of embedded tables and font elements.  It does
not use CSS at all.
 
 Jon:
   Correct.
 
 Me:
  I don't know much about anakia, but I know more about xhtml and css
  than I do about java (sadly so =). I'll volunteer.
 
 http://www.leosimons.com/scratchpad



site-proposal.vsl
Description: application/cnet-vsl

body, td {
			background-color: white;
			color: black;
			font-family: Arial, Helvetica, sans-serif;
			font-size: 11pt;
}
p {
	 		text-align: justify;
}
div {
			margin: 0px;
			padding: 0px;
}
h1, h2, h3, h4, h5, h6 {
			background-color: #003366;
			color: white;
			font-family: Verdana, Arial, sans-serif;
			font-weight: bold;
			padding-left: 5px;
			padding-right: 5px;
			padding-top: 2px;
			padding-bottom: 2px;
			margin: 0px;
}
h1 {
			font-size: 18pt;
}
h2 {
			font-size: 13pt;
}
h3 {
			font-size: 11pt;
}
h4 {
			font-size: 10pt;
}
h5 {
			font-size: 10pt;
}
h6 {
			font-size: 10pt;
}
a, a:visited {
			color: #336699;
}
a:hover, a:active {
			color: #003366;;
}
#contents div { margin-left: 40px; }
#breadcrumbs {
			border-top: 1px solid #003366;
			border-bottom: 1px solid #003366;
			margin-top: 10px;
			margin-bottom: 20px;
			padding-top: 0px;
			padding-bottom: 2px;
			padding-left: 10px;
			font-size: 10pt;
			font-weight: bold;
}
#menu {
			border-top: 1px solid #003366;
			border-left: 1px solid #003366;
			border-right: 1px solid #003366;
			border-bottom: 1px solid #003366;
			width: 175px;
}
#submenu ul {
			margin-top: 5px;
			margin-bottom: 5px;
			margin-left: 25px;
}
#footer {
			border-top: 1px solid #003366;
			margin-top: 20px;
			padding: 3px;
			text-align: center;
			font-size: 9pt;
			font-style: italic;
}
a.breadcrumbs, a.breadcrumbs:visited, a.menu, a.menu:visited {
			font-size: 10pt;
			font-weight: bold;
			text-decoration: none;
}
a.breadcrumbs:hover, a.breadcrumbs:active, a.menu:hover, a.menu:active {
			text-decoration: underline;
}
.code {
			font-family: Courier, Courier New, monospace;
}
.section .code {
			margin-left: -40px;
}
@media print {
	body td {
		font-family: Times New Roman, Zurich Bt, serif;
		font-size: 10pt;
	}
	h1 h2 h3 h4 h5 h6 {
		page-break-after: avoid;
		color: black;
		background-color: transparent;
		padding: 0px;
	}
	h1 {
		margin-left: 40px;
	}
	h2 {
		margin-left: 80px;
	}
	h3 {
		margin-left: 120px;
	}
	h4 {
		margin-left: 160px;
		font-style: italic;
	}
	#menu h4 {
		margin-left: 0px;
	}
	h5 {
		text-align: center;
	}
	h6 {
		text-align: center;
		font-style: italic;
	}
	.code {
		page-break-inside: avoid;
	}
	p ul {
		page-break-inside: avoid;
	}
	.section .code {
		margin-left: 0px;
	}
	#menu {
		display: none;
		width: 0px;
	}
	#contents div {
		margin: 0px;
	}
}




site.vsl.diff
Description: Binary data

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


RE: Misspelling

2002-03-27 Thread Larry Isaacs

Fixed.

Larry

 -Original Message-
 From: Pier Fumagalli [mailto:[EMAIL PROTECTED]] 
 Sent: Wednesday, March 27, 2002 2:56 PM
 To: Jakarta General List
 Subject: FW: Misspelling
 
 
 
 -- Forwarded Message
 From: Kennedy, Scott, MDCT Trenton [EMAIL PROTECTED]
 Date: Wed, 27 Mar 2002 14:21:26 -0500
 To: [EMAIL PROTECTED]
 Subject: Misspelling
 
 
 
http://jakarta.apache.org/site/news.html#0327.1

release is misspelled as relase

Regards,
Scott


-- End of Forwarded Message


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

--
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 Morgan Delagrange


- Original Message -
From: Ceki Gülcü [EMAIL PROTECTED]
To: Jakarta General List [EMAIL PROTECTED]
Sent: Wednesday, March 27, 2002 2:43 PM
Subject: RE: Comments on the commons-logging API


 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.

But it doesn't facilitate it either.

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.

Even if all Commons components used the same logging implementation (Log4J
for example), other projects in Jakarta-land may choose otherwise.  If you
add enough Jakarta projects to your environment, you eventually end up with
the scenario described above.  It's a worthwhile effort to attempt a logging
solution that plays well with the Jakarta community at large.  I think in
many cases the Commons Logging component can fill that role.

To take your analogy of trading a nickel's worth of functionality for a
penny payoff later (only because I'm dying to play off of it, FEEL FREE TO
IGNORE THIS PARAGRAPH :), yes each logger implementation delivers that
nickel.  However Log4J is delivering a US nickel, LogKit a Canadian nickel,
and JDK 1.4 a wooden nickel.  Each end-user becomes a bank that must
constantly monitor the exchange rate between those nickels, including those
wooden nickels which aren't worth a damn.  Some banks would prefer the
guarantee of a good penny than deal with the hassle of all those nickels.
:)

 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.


I don't know if the word dictate quite captures it.


 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.

It may be difficult to maintain.  The most we can do to mitigate it is
frequent releases and careful version management.

 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 

RE: Comments on the commons-logging API

2002-03-27 Thread costinm

On Wed, 27 Mar 2002, Ceki Gülcü wrote:

 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. 

And the user will have to configure and use 2 loggers. Or maybe 3, 4 or 
more - depending on how many libraries he uses.

If I write an application and I choose log4j, I would like a single config 
file and a consistent behavior for all the components. Same if I choose 
logkit or jdk1.4. The user ( or tomcat, etc ) may have scripts, UI, 
security settings etc.


 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.

If the bean developer is using commons-logging, he'll benefit of whatever 
user interface/setting/controls Jboss or tomcat provides.


Costin


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




subproject layout conventions

2002-03-27 Thread Leo Simons

It has been brought up by many people that there
is no common way of organising subproject websites.
I propose we draft a set of guidelines (_not_
rules) on a general structure.

Lets start with some discussion :)
---
Navigation / Organisation
---
The current website is presented as three layers:

- Jakarta main
- subproject main
- subproject menu
- subproject submenu

so the deepest level you end up in is

jakarta  subproject  section  webpage #position-on-webpage

The jakarta site has grown a lot bigger than supported
in such a hierarchy, hence the problems. Some projects
try to adhere closely to unofficial convention by
adding a layer:

- jakarta main
- subproject main
- sub-subproject main
- sub-subproject submenu

jakarta  subproject  sub-subproject  section  webpage
#position-on-webpage

while maintaining the layout. Avalon is an example.
Recently, Turbine has chosen a new layout to add this
extra level.

I don't really like this solution, as it will likely prove
to be inadequate in time. Also, subprojects that organise
themselves differently according to different criteria might
not fit into such a layout IMHO, we should have arbitrarily
deep levels, and a navigation structure which reflects
this.

There are five main approaches in websites tackling this:

1) breadcrumb trail
site  subsection  ...  subsection  page
example: www.dmoz.org

2) GUI-style menubar.
Your browser probably has one. Requires DHTML or similar
technology, _still_ doesn't seem to work well (ie combined
with html forms etc). example:
http://www.webreference.com/dhtml/hiermenus/

3) GUI-directory style tree.
Don't know of a file browser that hasn't got one (ok, so
you can do something different in MacOS 10, so what?).
Also requires DHTML or similar technology to work; scripts
available that _do_ work well.
example: http://msdn.microsoft.com/library

4) keyword-associated.
Kinda difficult to create by hand; WikiWiki's are usually
structured into tree-like structures by many people.
example: http://c2.com/cgi/wiki

5) criterium-selected.
An example is slashdot where the criterium is date of
placement. Older items fade into oblivion.

Each of these is often accompanied by a keyword-based search
facility, and depending on the site can have specific search
options as well.

They can, of course, be combined.

There are, of course, silly sites that have an approach that's
different from these. Users get lost on those.

So far for stating the obvious.

I would like to combine #1 with listing a limited tree containing
the current subsection and the parent subsection. Its scalable and
simple, and degrades well towards older browsers. Also, it is very
commonly used on many websites so users are familiar with it.

---
Common Sections
---
These can only be commonly defined to a limited extent. However,
recognising that we are dealing with open source software projects
means the subproject sites (can/probably should) have more than
just a navigation structure in common.

For each subproject, I propose, based on what the various projects
are currently doing, the following sections and subsections:

Essentials
- Overview
- News and Status
- Features
- Downloads
- project specifics

Documentation
- Installation
- Getting Started
- Tutorial
- User Guide
- Developer Guide
- Javadocs
- project specifics

Development
- Changes
- Todo
- Proposals
- Resolutions
- References
- project specifics

project specifics

for subprojects that do not have further subprojects. For
those that do, I propose the following sections and subsections:

Essentials
- Overview
- News and Status
- Downloads
- project specifics

Subprojects
- list of subprojects

Development
- Changes
- Todo
- Proposals
- Resolutions
- References
- project specifics

project specifics


regards,

- Leo Simons


--
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 costinm

On Wed, 27 Mar 2002, Ceki Gülcü wrote:

 At 10:15 27.03.2002 -0800, [EMAIL PROTECTED] wrote:
 The goal is not to be able to change the logger at compile time, but to be
 able to detect the platform logger and use it. The only way to do that is
 via a standard API - and commons-logging seems to be the only standard for
 logging that we have, supported ( mostly unwillingly :-) on all logging
 implementations. If you are concerned about the user experience with
 commons-logging and log4j, the best way to resolve that is by
 participating in commons-logging and implementing it in log4j so that
 log4j will work best with commons-logging.
 
 Rodney argued that the goal was to make commons components
 non-intrusive with respect to logging.

Well, there are more than 2 goals :-)


 If the goal is to detect (or guess) at run time the logging API to
 use, then this will only increase uncertainty and confusion. I know of
 a few frameworks (no, I won't tell you the names) that do this and it
 does not provide for a pleasant experience. Even I had trouble to set
 up logging and just gave up.

No, 'detecting/guessing' is not a goal - it's just one possible 
implementation - for the goal of allowing multiple implementations.

The goal here is to support multiple logging _implemementations_,
and provide a common/standard API for components to use.

By 'standard API' I mean the same thing as SAX - if you use SAX
your code will work with any parser that implements the SAX API.

It's certain that each parser ( and logger ) may have some better
internal APIs.


 To be brutally honest, I think the commons-logging approach is counter
 productive. It may seem like the politically correct thing to do but
 it will increase complexity and prove to be unproductive in the long
 run.  I thank you for the invitation to participate in the

I don't know any alternative to commons-logging. If you know any, I would
be happy to learn about it. Without an alternative, the only possible
approach is to improve commons-logging. 

Using log4j API and doing 'string replace' if you want to use another 
logger is absurd, I hope you weren't serious about proposing that. 

Unfortunately JDK1.4 logging API is not useable as a 'standard' for 
logging, and no other accepted standard exist (AFAIK). 

We have multiple logging implementations, and the only solution I know
is to use an API that works will all of them. I don't know what's
'conter productive' about it, it worked fine for SAX.

Costin




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




Re: subproject layout conventions

2002-03-27 Thread Jason van Zyl

On Wed, 2002-03-27 at 17:13, Leo Simons wrote:
 It has been brought up by many people that there
 is no common way of organising subproject websites.
 I propose we draft a set of guidelines (_not_
 rules) on a general structure.

http://jakarta.apache.org/turbine/maven/

There's a sample structure there, with lots of documentation and the
printable pages issue is dealt with.


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

Jason van Zyl
[EMAIL PROTECTED]

http://tambora.zenplex.org


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




RE: subproject layout conventions

2002-03-27 Thread Steven Noels

Leo Simons wrote:

 It has been brought up by many people that there
 is no common way of organising subproject websites.
 I propose we draft a set of guidelines (_not_
 rules) on a general structure.

 Lets start with some discussion :)

All this and more is being tackled (slowly but steadily) in Forrest -
and having some Jakarta people involved for cross-pollination would be
good.

There's not much yet except for the foundation and build environment and
some static site generation, but you could familiarize yourself using
http://marc.theaimsgroup.com/?l=forrest-devr=1w=2 and
http://cvs.apache.org/viewcvs.cgi/xml-forrest/

Regards,

/Steven


--
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 costinm

On Wed, 27 Mar 2002, Ceki Gülcü wrote:

 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).

The goals of commons-logging ( as I understand them ):
- non-intrusiveness
- convenience
- multiple implementations
- simple to use
- secure 
- useable in container environment 
( and probably more )

Each of those goals is important. 



 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.

Not quite - it's the same mechansim used for JAXP detection. You can
set a logging API explicitely if you want ( system property - no 
confusion here ). 

Detection is used to simplify users' life and reduce the number of 
required settings. The only possible problem is if the user has
multiple loggers installed ( in which case he should use the explicit 
setting if he feels the need) . 


Costin


--
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 Morgan Delagrange


- Original Message -
From: Ceki Gülcü [EMAIL PROTECTED]
To: Jakarta General List [EMAIL PROTECTED]
Sent: Wednesday, March 27, 2002 4:20 PM
Subject: Re: Comments on the commons-logging API


 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).

Yes, the defining advantage to the commons-logging API that I see is that it
allows users to adopt a single logging implementation, which confers real
benefits particularly with regard to configuration.  Easy transitions from
one logging implementation to another are not particularly important; the
tangible benefit is to let disparate components have the _option_ to use the
same log without complicated bridges between logging implementations.

 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.


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


_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
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]




Re: subproject layout conventions

2002-03-27 Thread Jon Scott Stevens

on 3/27/02 2:26 PM, Steven Noels [EMAIL PROTECTED] wrote:

 All this and more is being tackled (slowly but steadily) in Forrest -
 and having some Jakarta people involved for cross-pollination would be
 good.
 
 There's not much yet except for the foundation and build environment and
 some static site generation, but you could familiarize yourself using
 http://marc.theaimsgroup.com/?l=forrest-devr=1w=2 and
 http://cvs.apache.org/viewcvs.cgi/xml-forrest/

I think Maven will be the pants off forrest and is already further along.

-jon


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




Re: subproject layout conventions

2002-03-27 Thread Jeff Turner

On Wed, Mar 27, 2002 at 03:23:35PM -0800, Jon Scott Stevens wrote:
 on 3/27/02 2:26 PM, Steven Noels [EMAIL PROTECTED] wrote:
 
  All this and more is being tackled (slowly but steadily) in Forrest -
  and having some Jakarta people involved for cross-pollination would be
  good.
  
  There's not much yet except for the foundation and build environment and
  some static site generation, but you could familiarize yourself using
  http://marc.theaimsgroup.com/?l=forrest-devr=1w=2 and
  http://cvs.apache.org/viewcvs.cgi/xml-forrest/
 
 I think Maven will be the pants off forrest and is already further along.

I agree (as much as I like Cocoon and the Centipede build system). Maven
could be a revolution on the scale of Gump.


--Jeff

 -jon
 

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




Re: subproject layout conventions

2002-03-27 Thread dion

Jason van Zyl [EMAIL PROTECTED] wrote on 28/03/2002 08:15:53 AM:

 On Wed, 2002-03-27 at 17:13, Leo Simons wrote:
  It has been brought up by many people that there
  is no common way of organising subproject websites.
  I propose we draft a set of guidelines (_not_
  rules) on a general structure.
 
 http://jakarta.apache.org/turbine/maven/
 
 There's a sample structure there, with lots of documentation and the
 printable pages issue is dealt with.

Hey Jason, don't undersell Maven :) It's a godsend for projects.

Not only does Maven provide docs, pages but it also helps with jar file 
downloading, dependencies, mailing lists, build file reuse, metrics, code 
cross reference and more.

Bring it on!

 -- 
 jvz.
 
 Jason van Zyl
 [EMAIL PROTECTED]
 
 http://tambora.zenplex.org

--
dIon Gillard, Multitask Consulting
Work:  http://www.multitask.com.au
Developers: http://adslgateway.multitask.com.au/developers


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




BCEL?

2002-03-27 Thread Scott Vachalek

Hello,

I have a BCEL bug to report but there doesn't seem to be a category for it in the bug 
database.  Should it go somewhere else or can you create a category?  

Thanks,
Scott



Re: subproject layout conventions

2002-03-27 Thread Nicola Ken Barozzi

From: Steven Noels [EMAIL PROTECTED]

 Leo Simons wrote:

  It has been brought up by many people that there
  is no common way of organising subproject websites.
  I propose we draft a set of guidelines (_not_
  rules) on a general structure.
 
  Lets start with some discussion :)

 All this and more is being tackled (slowly but steadily) in Forrest -
 and having some Jakarta people involved for cross-pollination would be
 good.

 There's not much yet except for the foundation and build environment and
 some static site generation, but you could familiarize yourself using
 http://marc.theaimsgroup.com/?l=forrest-devr=1w=2 and
 http://cvs.apache.org/viewcvs.cgi/xml-forrest/

BTW, there are three available skins there, for Jakarta, xml-apache and
scarab-like.

If any project doesn't want to mess with site generation, just ask me or
even better on the Forrest mailing list
([EMAIL PROTECTED]) and we will set it up for them.

Thank you.

--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-


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