You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Christian Schneider <ch...@die-schneider.net> on 2008/10/07 00:24:47 UTC
How to handle a configuration problem generally in CXF code
Hi all,
when there is a problem with the configuration i currently throw a
simple RuntimeException. I think this can be handled better.
I have found a class ConfigurationException but it only accepts a
message as i18 Message. Should this class be used? I do not like that
much that it always needs a resource definition.
Is internationalization for config errors that usefull? Whenever I got a
german exception I had much problems trying to google for it. So I
personally like english exceptions.
Another possibility would be to throw an AssertionError. As it is for
example an assertion that a certain property is not null.
Any ideas?
Greetings
Christian
--
Christian Schneider
---
http://www.liquid-reality.de
Re: How to handle a configuration problem generally in CXF code
Posted by Glen Mazza <gl...@gmail.com>.
Yes, it was good that James Mao created a CXF-zh list, with so many Chinese
committers, developing a Chinese language CXF community was a huge bonus for
us that the other web service stacks didn't have. Doing Google blog
searches, we do seem to lag in Japan though because the Axis 1.x web site is
translated into Japanese.
Glen
dkulp wrote:
>
>
> I'd definitely prefer if the excpetion was on of the I18N things. A
> LARGE chunk of our users are actually from China. According to google
> analytics, China is #2 after the US. It's definitely important to keep
> the option open to make this stuff localizable. ESPECIALLY for
> configuration things where a non-developer might need to make changes.
> More "admin" like tasks.
>
> Note: if you have a Logger, you already have the bundle. The i18n
> message can take the Logger instead of the bundle.
>
> Dan
>
>
> On Monday 06 October 2008, Christian Schneider wrote:
>> Hi all,
>>
>> when there is a problem with the configuration i currently throw a
>> simple RuntimeException. I think this can be handled better.
>> I have found a class ConfigurationException but it only accepts a
>> message as i18 Message. Should this class be used? I do not like that
>> much that it always needs a resource definition.
>> Is internationalization for config errors that usefull? Whenever I got
>> a german exception I had much problems trying to google for it. So I
>> personally like english exceptions.
>> Another possibility would be to throw an AssertionError. As it is for
>> example an assertion that a certain property is not null.
>>
>> Any ideas?
>>
>> Greetings
>>
>> Christian
>
>
>
> --
> J. Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
>
--
View this message in context: http://www.nabble.com/How-to-handle-a-configuration-problem-generally-in-CXF-code-tp19847560p19867935.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Re: How to handle a configuration problem generally in CXF code
Posted by Daniel Kulp <dk...@apache.org>.
On Wednesday 08 October 2008 7:17:59 pm Christian Schneider wrote:
> I would propose to add the following to UncheckedException and
> corresponding "super" calls to all exceptions.
>
> public UncheckedException(String code, ResourceBundle bundle,
> Object...params) {
> this(new Message(code, bundle, params));
> }
>
> public UncheckedException(String code, Throwable t, ResourceBundle
> bundle, Object...params) {
> this(new Message(code, bundle, params), t);
> }
>
> To use these you could do the following at the start of the class:
> static final Logger LOG =
> LogUtils.getL7dLogger(JMSConfigFeature.class); static final ResourceBundle
> BUNDLE = LOG.getResourceBundle();
>
> and then:
> throw new ConfigurationException("JMSCONFIGFEATURE_ONLY_JMS", BUNDLE);
Works for me. A convienience constructor like:
public UncheckedException(String code, Logger log, Object...params) {
this(new Message(code, log.getResourceBundle(), params));
}
might be nice to avoid having extra derivable instance variables, but not
really important.
> I have checked where the i18n Message is used and it seems only to be
> used for exceptions. So would it perhaps make sense to deprecate it and
> always create exceptions like above?
> Was there a special reason for the introduction of i18n Message?
Probably. It was originally (like REALLY REALLY long time ago) also used for
Logging before we settled on j.u.l since most logging kits don't support
resource bundles. Thus, we needed that just to log i18n messages. Once
we settled on j.u.l, it probably should have been changed.
> Any opinions?
Go for it. :-)
Dan
>
> Greetings
>
> Christian
>
> Benson Margulies schrieb:
> > I'm +1 to the constructor. I find the new-ing of messages to be a pain.
> >
> > On Tue, Oct 7, 2008 at 5:27 PM, Christian Schneider
> > <chris@die-schneider.net
> >
> >> wrote:
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Re: How to handle a configuration problem generally in CXF code
Posted by Benson Margulies <bi...@gmail.com>.
Are you sure that none of the tools are using the Message class directly?
The message class still seems to be good modularity to me. I'm +1 on
the new constructors, all the same.
On Wed, Oct 8, 2008 at 7:17 PM, Christian Schneider
<ch...@die-schneider.net> wrote:
> I would propose to add the following to UncheckedException and corresponding
> "super" calls to all exceptions.
>
> public UncheckedException(String code, ResourceBundle bundle,
> Object...params) {
> this(new Message(code, bundle, params));
> }
> public UncheckedException(String code, Throwable t, ResourceBundle
> bundle, Object...params) {
> this(new Message(code, bundle, params), t);
> }
>
> To use these you could do the following at the start of the class:
> static final Logger LOG = LogUtils.getL7dLogger(JMSConfigFeature.class);
> static final ResourceBundle BUNDLE = LOG.getResourceBundle();
>
> and then:
> throw new ConfigurationException("JMSCONFIGFEATURE_ONLY_JMS", BUNDLE);
>
> I have checked where the i18n Message is used and it seems only to be used
> for exceptions. So would it perhaps make sense to deprecate it and always
> create exceptions like above?
> Was there a special reason for the introduction of i18n Message?
> Any opinions?
>
> Greetings
>
> Christian
>
>
> Benson Margulies schrieb:
>>
>> I'm +1 to the constructor. I find the new-ing of messages to be a pain.
>>
>> On Tue, Oct 7, 2008 at 5:27 PM, Christian Schneider
>> <chris@die-schneider.net
>>
>>>
>>> wrote:
>>>
>>
>>
>
>
> --
>
> Christian Schneider
> ---
> http://www.liquid-reality.de
>
>
Re: How to handle a configuration problem generally in CXF code
Posted by Christian Schneider <ch...@die-schneider.net>.
I would propose to add the following to UncheckedException and
corresponding "super" calls to all exceptions.
public UncheckedException(String code, ResourceBundle bundle,
Object...params) {
this(new Message(code, bundle, params));
}
public UncheckedException(String code, Throwable t, ResourceBundle
bundle, Object...params) {
this(new Message(code, bundle, params), t);
}
To use these you could do the following at the start of the class:
static final Logger LOG = LogUtils.getL7dLogger(JMSConfigFeature.class);
static final ResourceBundle BUNDLE = LOG.getResourceBundle();
and then:
throw new ConfigurationException("JMSCONFIGFEATURE_ONLY_JMS", BUNDLE);
I have checked where the i18n Message is used and it seems only to be
used for exceptions. So would it perhaps make sense to deprecate it and
always create exceptions like above?
Was there a special reason for the introduction of i18n Message?
Any opinions?
Greetings
Christian
Benson Margulies schrieb:
> I'm +1 to the constructor. I find the new-ing of messages to be a pain.
>
> On Tue, Oct 7, 2008 at 5:27 PM, Christian Schneider <chris@die-schneider.net
>
>> wrote:
>>
>
>
--
Christian Schneider
---
http://www.liquid-reality.de
Re: How to handle a configuration problem generally in CXF code
Posted by Benson Margulies <bi...@gmail.com>.
I'm +1 to the constructor. I find the new-ing of messages to be a pain.
On Tue, Oct 7, 2008 at 5:27 PM, Christian Schneider <chris@die-schneider.net
> wrote:
> Hi Dan,
>
> I have included a first exception. It looks like this:
>
> org.apache.cxf.common.i18n.Message msg = new
> org.apache.cxf.common.i18n.Message("INSUFFICIENT_CONFIGURATION_CONDUIT",
> LOG, name);
> throw new ConfigurationException(msg);
>
> This looks extremly ugly as Message is already imported either as a CXF
> message or a JMS message. It will be even uglier when the code formatter has
> done its work.
>
> Is it necessary that the Message is built with new? Can´t we simply do
> something like this:
> throw new ConfigurationException("INSUFFICIENT_CONFIGURATION_CONDUIT", LOG,
> name);
>
> We could add this Constructor to UncheckedException.
>
> Greetings
>
> Christian
>
>
> Daniel Kulp schrieb:
>
>> I'd definitely prefer if the excpetion was on of the I18N things. A
>> LARGE chunk of our users are actually from China. According to google
>> analytics, China is #2 after the US. It's definitely important to keep the
>> option open to make this stuff localizable. ESPECIALLY for configuration
>> things where a non-developer might need to make changes. More "admin" like
>> tasks.
>> Note: if you have a Logger, you already have the bundle. The i18n
>> message can take the Logger instead of the bundle.
>>
>> Dan
>>
>>
>>
>
>
> --
>
> Christian Schneider
> ---
> http://www.liquid-reality.de
>
>
Re: How to handle a configuration problem generally in CXF code
Posted by Christian Schneider <ch...@die-schneider.net>.
Hi Dan,
I have included a first exception. It looks like this:
org.apache.cxf.common.i18n.Message msg = new
org.apache.cxf.common.i18n.Message("INSUFFICIENT_CONFIGURATION_CONDUIT",
LOG, name);
throw new ConfigurationException(msg);
This looks extremly ugly as Message is already imported either as a CXF
message or a JMS message. It will be even uglier when the code formatter
has done its work.
Is it necessary that the Message is built with new? Can´t we simply do
something like this:
throw new ConfigurationException("INSUFFICIENT_CONFIGURATION_CONDUIT",
LOG, name);
We could add this Constructor to UncheckedException.
Greetings
Christian
Daniel Kulp schrieb:
> I'd definitely prefer if the excpetion was on of the I18N things. A
> LARGE chunk of our users are actually from China. According to google
> analytics, China is #2 after the US. It's definitely important to keep
> the option open to make this stuff localizable. ESPECIALLY for
> configuration things where a non-developer might need to make changes.
> More "admin" like tasks.
>
> Note: if you have a Logger, you already have the bundle. The i18n
> message can take the Logger instead of the bundle.
>
> Dan
>
>
--
Christian Schneider
---
http://www.liquid-reality.de
Re: How to handle a configuration problem generally in CXF code
Posted by Daniel Kulp <dk...@apache.org>.
I'd definitely prefer if the excpetion was on of the I18N things. A
LARGE chunk of our users are actually from China. According to google
analytics, China is #2 after the US. It's definitely important to keep
the option open to make this stuff localizable. ESPECIALLY for
configuration things where a non-developer might need to make changes.
More "admin" like tasks.
Note: if you have a Logger, you already have the bundle. The i18n
message can take the Logger instead of the bundle.
Dan
On Monday 06 October 2008, Christian Schneider wrote:
> Hi all,
>
> when there is a problem with the configuration i currently throw a
> simple RuntimeException. I think this can be handled better.
> I have found a class ConfigurationException but it only accepts a
> message as i18 Message. Should this class be used? I do not like that
> much that it always needs a resource definition.
> Is internationalization for config errors that usefull? Whenever I got
> a german exception I had much problems trying to google for it. So I
> personally like english exceptions.
> Another possibility would be to throw an AssertionError. As it is for
> example an assertion that a certain property is not null.
>
> Any ideas?
>
> Greetings
>
> Christian
--
J. Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
Re: How to handle a configuration problem generally in CXF code
Posted by Benson Margulies <bi...@gmail.com>.
I try to get rid of naked RuntimeExceptions whenever I can. If a problem can
be caused by user error or system config, it should throw a class of ours,
and it should support I18N, as far as I've understood our conventions.
On Mon, Oct 6, 2008 at 6:24 PM, Christian Schneider <chris@die-schneider.net
> wrote:
> Hi all,
>
> when there is a problem with the configuration i currently throw a simple
> RuntimeException. I think this can be handled better.
> I have found a class ConfigurationException but it only accepts a message
> as i18 Message. Should this class be used? I do not like that much that it
> always needs a resource definition.
> Is internationalization for config errors that usefull? Whenever I got a
> german exception I had much problems trying to google for it. So I
> personally like english exceptions.
> Another possibility would be to throw an AssertionError. As it is for
> example an assertion that a certain property is not null.
>
> Any ideas?
>
> Greetings
>
> Christian
>
> --
>
> Christian Schneider
> ---
> http://www.liquid-reality.de
>
>