On 29 Jan 2004, at 07:28, Craig R. McClanahan wrote:
snip
Before a real 1.0 release I would really like to see a JDBC based
implementation
added, but that doesn't need to be a gating factor for promotion to
commons
proper (especially if I don't have time to work on it, although it's
becoming
This case sounds like a contract violation on the part of the caller, so
throwing IllegalArgumentException is entirely reasonable. In fact that's
exactly what I advise for all caller-side contract violations.
On Thu, 29 Jan 2004 14:17:46 -0500, Inger, Matthew [EMAIL PROTECTED]
said:
I had also
[Sorry, premature message send.]
Mark R. Diggory wrote:
I don't think logging should be used for anything more than debugging
purposes.
J.Pietschmann said:
Me too. I used the code snippet as an example of a typical application
level exception handling.
I don't think a library must bend
Bad name, implies it's a Throwable but it's not. Also you wouldn't want to
make it extend that.
LocalizedMessageSource? and change getResourceKey to getMessageKey ?
Other names: LocalizedMessagable LocalizedThrowableMessagable etc.
[not that I'm agreeing with the interface's need, just
Henri Yandell wrote:
LocalizedMessageSource? and change getResourceKey to getMessageKey ?
Other names: LocalizedMessagable LocalizedThrowableMessagable etc.
Sounds good, but the scope should be [lang], [ressource] or the
yet-to-create [i18n] project.
J.Pietschmann
If it's all that is defined in the proposal, I think lang is fine. If it
all grows beyond that, I have my doubts that it would be right in lang
because it will most likely have become an i18n thing and not just a nice
marker for throwables.
Hen
On Fri, 30 Jan 2004, J.Pietschmann wrote:
Henri
]
Sent: Friday, January 30, 2004 5:37 PM
To: Jakarta Commons Developers List
Subject: Re: [lang] i18n package proposal
If it's all that is defined in the proposal, I think lang is fine. If it
all grows beyond that, I have my doubts that it would be right in lang
because it will most likely have
I am -1 to adding behaviour to do with localized messages into [lang]. It
gets way too complex and religious and just doens't fit.
Stephen
From: Henri Yandell [EMAIL PROTECTED]
If it's all that is defined in the proposal, I think lang is fine. If it
all grows beyond that, I have my doubts
Quoting Martin Cooper [EMAIL PROTECTED]:
On Wed, 28 Jan 2004, Mark R. Diggory wrote:
Ask those developing it for a status.
Resources developers, what is the status of resources, how close are you
to releasing?
It's partly my fault, I suspect, that it isn't further down the pike.
have a full release version use routines from the sandbox
libraries.
-Original Message-
From: robert burrell donkin
[mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 28, 2004 6:13 PM
To: Jakarta Commons Developers List
Subject: Re: [lang] i18n package proposal
but all proper
]
Sent: Thursday, January 29, 2004 8:52 AM
To: Jakarta Commons Developers List
Subject: Re: [lang] i18n package proposal
Inger, Matthew wrote:
Math does not need to be localized in a lot of places, but
exception messages should be localized. This is a common thing
that people miss. If i am
Ultimately your going to also have to deal with the fact that a
underlying dependency may have thrown the exception, you can't guarantee
that the dependency is going to be localized.
Also, its usually the case that users end up posting stack traces to the
list in hopes of getting some
-Original Message-
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 29, 2004 07:28 AM
To: 'Jakarta Commons Developers List'
Subject: Re: [resources] status was (Re: [lang] i18n package proposal)
Quoting Martin Cooper [EMAIL PROTECTED]:
On Wed, 28 Jan
Phil Steitz wrote:
I am with Henri here. I would not expect error messages from [math] (or
[collections] or [lang], etc.) to be passed up directly to a gui or end
user console. Designing and managing error messages for the end user to
see should happen at the application level, supported by
To: Jakarta Commons Developers List
Subject: Re: [lang] i18n package proposal
Phil Steitz wrote:
I am with Henri here. I would not expect error messages from [math] (or
[collections] or [lang], etc.) to be passed up directly to a gui or end
user console. Designing and managing error messages
J.Pietschmann wrote:
Phil Steitz wrote:
I am with Henri here. I would not expect error messages from [math]
(or [collections] or [lang], etc.) to be passed up directly to a gui
or end user console. Designing and managing error messages for the end
user to see should happen at the application
Developers List; '[EMAIL PROTECTED]'
Subject: RE: [lang] i18n package proposal
At 4:43 PM -0500 1/28/04, Inger, Matthew wrote:
Any interest in an i18n package for lang? I think it would be helpful for
a applications to have a foundation for i18n and string externalization.
Presenting a common
.
-Original Message-
From: Joe Germuska [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 28, 2004 5:45 PM
To: Jakarta Commons Developers List; '[EMAIL PROTECTED]'
Subject: RE: [lang] i18n package proposal
At 4:43 PM -0500 1/28/04, Inger, Matthew wrote:
Any interest in an i18n package for lang? I think
18 matches
Mail list logo
