You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Ole Bulbuk <Ol...@ebp.de> on 2002/04/23 19:40:27 UTC
Do you *really* not need localized exceptions?
Hi,
I have noticed that there exists a package org.apache.avalon.excalibur.i18n
that supports internationalization/localization. So I suppose somebody is
using it. The thing I usually need most on the server side is localized
exceptions since they might be shown to the user (e. g. in a message box) on
the client side. And I don't really like to ignore this like Sun and all the
others who just create exceptions with hard coded (english text) strings.
Even M$ doesn't bother a user with english error messages on a german
Windows. And I really don't want to be under the standard of M$. So I really
would like to solve this problem and I suppose the problem is common enough
for the solution to be provided somewhere under the avalon umbrella.
I usually create an abstract base I18nException/L7dException for this, that
is
really returning a localized message when getLocalizedMessage() is called.
It could/should extend CascadingException and provide something like the
following constructors:
1. I18nException(Object hint, Serializable[] params, Throwable cause)
2. I18nException(Serializable[] params, Throwable cause)
3. I18nException(Serializable[] params)
4. I18nException(Object hint, Serializable[] params)
The hint would help in finding the right format string (added to the FCQN of
the exception) from a excalibur.i18n.Resources. Implementations would
provide static format strings for the getMessage() method or if the
resources aren't found. So there shouldn't be any performance issues when
getLocalizedMessage() isn't used.
The params are used as the arguments array to MessageFormat.format() and the
cause is of course used for the CascadingException.
I would be willing to provide such an exception class if desired.
I suppose it would be best to have it in the
org.apache.avalon.excalibur.i18n package since people who don't care about
i18n won't make use of it anyway.
Otherwise I will put it in a EBP (company) package if you aren't interested.
Getting it out later will be more difficult since people here might think I
stole it from the company.
Of course it would be nice to be able to configure the logging mechanism to
use the getLocalizedMessage() method. So the system administrator will get
messages he is able to understand (logging the name of the exception, the
hint and the params might be even better if the log file is read via a
special application, so a german administrator is able to administrate a
server located in Japan).
Regards,
Ole
P.S.: Sorry for the eye-catching style but my last message regarding this
subject was ignored?
--
Ole Bulbuk Tel.: 0331/74759/60
Ernst Basler + Partner Fax: 0331/74759/90
Tuchmacherstr. 47 E-Mail: mailto:ob@ebp.de
14482 Potsdam WWW: http://www.ebp.de
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Altrmi} Thoughts
Posted by Peter Royal <pr...@apache.org>.
On Wednesday 24 April 2002 12:42 pm, Vinay Chandran wrote:
> >> Right now CallbackEnabled client stream treats
> >> ALL of
> >> its arguments , which are interfaces , as
> >> pass by reference
> >
> > This is only for the callback object on the
> > CallbackEnabled stream, correct?
>
> Yes.
> Other streams treats every argument as
> pass-by-value and serializes it across.
IMHO the default behavior for the callback object should be pass-by-ref,
since I think in most cases if you have a callback you would want the logic
to execute on the client. But its a very usefull addition.
> I shall look into the other improvements I talked off
> as soon as I am done with writing stub-generators
> using BCEL.
excellent!
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Altrmi} Thoughts
Posted by Paul Hammant <pa...@yahoo.com>.
Vinay,
> <snip>
> >> Right now CallbackEnabled client stream treats
> >> ALL of
> >> its arguments , which are interfaces , as
> >> pass by reference
> > This is only for the callback object on the
> > CallbackEnabled stream, correct?
>
> Yes.
> Other streams treats every argument as
> pass-by-value and serializes it across.
Not true. If a parameter going back to the server from a client originated from the client
in that AND it was a pass-by-reference boundary, then it is not serialized (or transported as is).
Instead it is swapped for a it's original refernece. Swapped in that there is an array of
the args going back to the server for each method call.
> I shall look into the other improvements I talked off
> as soon as I am done with writing stub-generators
> using BCEL.
Excelent work dude. I did not think it was possible. I am not worthy etc...
-ph
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Altrmi} Thoughts
Posted by Vinay Chandran <vi...@yahoo.com>.
hi,
<snip>
>> Right now CallbackEnabled client stream treats
>> ALL of
>> its arguments , which are interfaces , as
>> pass by reference
> This is only for the callback object on the
> CallbackEnabled stream, correct?
Yes.
Other streams treats every argument as
pass-by-value and serializes it across.
I shall look into the other improvements I talked off
as soon as I am done with writing stub-generators
using BCEL.
Regards,
V i n a y
__________________________________________________
Do You Yahoo!?
Yahoo! Games - play chess, backgammon, pool and more
http://games.yahoo.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Altrmi} Thoughts
Posted by Peter Royal <pr...@apache.org>.
On Tuesday 23 April 2002 08:47 pm, Vinay Chandran wrote:
> <1 topic="Method Invocation" >
> How about replacing it with a int value ,which is
> nothing but a index to a method array maintained
> on the server for that specific remote object & thus
> in the process removing the string comparisons
> involved ?
+1
The less that can be sent is good for speed.
> <2 topic="Pass-by-Reference & Pass-by-value decision "
>
> Right now CallbackEnabled client stream treats ALL of
> its arguments , which are interfaces ,
This is only for the callback object on the CallbackEnabled stream, correct?
> //pass-by-reference .callbacks can be made on this
> reference by the server
> addCallBackListener(new
> PassReference(callBackTestListenerImpl));
If so, I prefer this syntax.
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Altrmi} Thoughts
Posted by Peter Donald <pe...@apache.org>.
On Fri, 26 Apr 2002 16:13, Paul Hammant wrote:
> > Basically I would like a simple API for making invocations on objects. It
> > should not be tied to any particular Object model or any transport layer
> > (as a matter of fact it sits right in between).
> >
> > I have attached a zip with the files in it that describe the API.
> > Basically there is 4 parts.
>
> I'll grant you that what we have is a tad more complicated than you have
> shown in the example you supplied, but I'd like to see that the general
> features match with what we have done so far. The chief difference as far
> as I can see is that we have generated proxies to make things look like
> normal java objects. Your interfaces do not illustrate an example usage of
> the interfaces, so I'll guess you intend both normal java usage and a
> reflection-like method.invoke(..) interface
Well I guess I was thinking it would be the layer between the generated
proxies and the actual transport. So in my view the generated proxies would
actually use this layer to do the actual transportation/work.
The reason for this level of separation is that it would make it easier to
support alternative models of distribution. ie If you wanted to write an EJB
server (where the EJBs don't actually deal with external transport layer and
one external "interface" may actually serve thousands of clients).
You probably can do it in your current model but it would be a PITA. You would
end up doing something like
Incoming call --> AltRMI interface --> discrete call objects (like I proposed)
--> specific EJB object
So I guess this model is less for end users and more for people who want to
build middleware based on AltRMI. Heh - if you went this way you could even
build regular RMI on top of this ;)
> > The reason for this architecture is that it would allow you to reliably
> > scale up as you are no longer tied to the single-thread per call model
> > and all sorts of goodies become apparent.
>
> We are not currently tied to any threading model. At least I think we are
> not. We can lump multiple threads on the client side together to call the
> server through the same altrmi connection.
Well what I was actually meaning was allowing the same thread to make multiple
calls without waiting for a response. ie You could end up with sequencing
like
call Method1
call Method2
call Method3
receive Method1 response
receive Method2 response
call Method4
receive Method4 response
receive Method3 response
Thus long running calls (like method3) will not tie up the whole thread - it
will just take longer to get a repsonse. I am not saying that this is needed
for regular clients but for certain systems it can be useful. (One of the
clients I work with currently has such an architecture in place).
> I think you are referring to server-side though in the context of one
> thread multiplexing though connections..
Thats another advantage ;)
--
Cheers,
Peter Donald
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Altrmi} Thoughts
Posted by Paul Hammant <pa...@yahoo.com>.
Peter,
> While ideas about altrmi are being gestated I would like to throw out some of
> mine. Note that this is probably not something that I can devote anytime to
> now but it is something I would find useful in long term.
:-)
> Basically I would like a simple API for making invocations on objects. It
> should not be tied to any particular Object model or any transport layer (as
> a matter of fact it sits right in between).
>
> I have attached a zip with the files in it that describe the API. Basically
> there is 4 parts.
I'll grant you that what we have is a tad more complicated than you have shown in the example you
supplied, but I'd like to see that the general features match with what we have done so far. The
chief difference as far as I can see is that we have generated proxies to make things look like
normal java objects. Your interfaces do not illustrate an example usage of the interfaces, so
I'll guess you intend both normal java usage and a reflection-like method.invoke(..) interface
> * Invocation: represents the call
> * InvocationContext: represents the context information like security id,
> transaction id etc.
We are mulling choices here but are likely to do the same.
> * Invoker: the thing that "executes" the Invocation - can be async or sync.
> * InvocationListener: The call back when running async invocations to notify
> that call has completed
>
> The reason for this architecture is that it would allow you to reliably scale
> up as you are no longer tied to the single-thread per call model and all
> sorts of goodies become apparent.
We are not currently tied to any threading model. At least I think we are not. We can lump
multiple threads on the client side together to call the server through the same altrmi
connection.
I think you are referring to server-side though in the context of one thread multiplexing though
connections..
>
> Anyways I just thought I would drop a few thoughts :)
keep em up dude...
-ph
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Altrmi} Thoughts
Posted by Peter Donald <pe...@apache.org>.
Hi,
While ideas about altrmi are being gestated I would like to throw out some of
mine. Note that this is probably not something that I can devote anytime to
now but it is something I would find useful in long term.
Basically I would like a simple API for making invocations on objects. It
should not be tied to any particular Object model or any transport layer (as
a matter of fact it sits right in between).
I have attached a zip with the files in it that describe the API. Basically
there is 4 parts.
* Invocation: represents the call
* InvocationContext: represents the context information like security id,
transaction id etc.
* Invoker: the thing that "executes" the Invocation - can be async or sync.
* InvocationListener: The call back when running async invocations to notify
that call has completed
The reason for this architecture is that it would allow you to reliably scale
up as you are no longer tied to the single-thread per call model and all
sorts of goodies become apparent.
Anyways I just thought I would drop a few thoughts :)
--
Cheers,
Peter Donald
[Altrmi} Thoughts
Posted by Vinay Chandran <vi...@yahoo.com>.
Hi,
Needed some inputs on the following topics within
AltRMI :-
<1 topic="Method Invocation" >
We have method signature(string) being passed from
the client to the server for
carrying out the invocation of a specific method on
the server.
How about replacing it with a int value ,which is
nothing but a index to a method array maintained
on the server for that specific remote object & thus
in the process removing the string comparisons
involved ?
Comments ??
</1>
<2 topic="Pass-by-Reference & Pass-by-value decision "
>
Right now CallbackEnabled client stream treats ALL of
its arguments , which are interfaces ,
as pass-by-reference entities and transports its stub
instead of passing it by value(serializing) to the
server.
We might need to employ some means to indicate an
argument as either Pass-By-Reference or POV
entity in the arguments.
We can do something like:
callBackTestListenerImpl = new
CallBackTestListenerImpl(2);
//pass-by-value ..serialized across..this is the
default
addCallBackListener(callBackTestListenerImpl);
//pass-by-reference .callbacks can be made on this
reference by the server
addCallBackListener(new
PassReference(callBackTestListenerImpl));
===or===
We can use something like RMI's exportObject(..)
Therefore:
CallBackTestListenerImpl callBackTestListenerImpl_1
= new CallBackTestListenerImpl(2);
CallBackTestListenerImpl callBackTestListenerImpl_2
= new CallBackTestListenerImpl(2);
//This specific reference will be passed by value
when its passed on to the server as an argument
AltrmiHost.exposeObject(callBackTestListenerImpl_2);
addCallBackListener(callBackTestListenerImpl_1);//pass-by-value
.serialized across
addCallBackListener(callBackTestListenerImpl_2);//pass-by-reference
..
Comments?
</2>
Regards,
V i n a y
__________________________________________________
Do You Yahoo!?
Yahoo! Games - play chess, backgammon, pool and more
http://games.yahoo.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Do you *really* not need localized exceptions?
Posted by Michael Nash <mi...@jglobalonline.com>.
Ole:
Comment from the peanut gallery: I definitely understand the need for localized exceptions (or the messages in the exceptions, anyway). Although the *user* might see a more polite (and internationalized) message, the sys admin for most of my clients isn't a native english-speaker either, so making them wade through an english message isn't my first choice.
Mike
On Tue, 23 Apr 2002 19:40:27 +0200
Ole Bulbuk <Ol...@ebp.de> wrote:
> Hi,
>
> I have noticed that there exists a package org.apache.avalon.excalibur.i18n
> that supports internationalization/localization. So I suppose somebody is
> using it. The thing I usually need most on the server side is localized
> exceptions since they might be shown to the user (e. g. in a message box) on
> the client side. And I don't really like to ignore this like Sun and all the
> others who just create exceptions with hard coded (english text) strings.
> Even M$ doesn't bother a user with english error messages on a german
> Windows. And I really don't want to be under the standard of M$. So I really
> would like to solve this problem and I suppose the problem is common enough
> for the solution to be provided somewhere under the avalon umbrella.
>
> I usually create an abstract base I18nException/L7dException for this, that
> is
> really returning a localized message when getLocalizedMessage() is called.
> It could/should extend CascadingException and provide something like the
> following constructors:
>
> 1. I18nException(Object hint, Serializable[] params, Throwable cause)
> 2. I18nException(Serializable[] params, Throwable cause)
> 3. I18nException(Serializable[] params)
> 4. I18nException(Object hint, Serializable[] params)
>
> The hint would help in finding the right format string (added to the FCQN of
> the exception) from a excalibur.i18n.Resources. Implementations would
> provide static format strings for the getMessage() method or if the
> resources aren't found. So there shouldn't be any performance issues when
> getLocalizedMessage() isn't used.
>
> The params are used as the arguments array to MessageFormat.format() and the
> cause is of course used for the CascadingException.
>
> I would be willing to provide such an exception class if desired.
> I suppose it would be best to have it in the
> org.apache.avalon.excalibur.i18n package since people who don't care about
> i18n won't make use of it anyway.
>
> Otherwise I will put it in a EBP (company) package if you aren't interested.
> Getting it out later will be more difficult since people here might think I
> stole it from the company.
>
> Of course it would be nice to be able to configure the logging mechanism to
> use the getLocalizedMessage() method. So the system administrator will get
> messages he is able to understand (logging the name of the exception, the
> hint and the params might be even better if the log file is read via a
> special application, so a german administrator is able to administrate a
> server located in Japan).
>
> Regards,
>
> Ole
>
> P.S.: Sorry for the eye-catching style but my last message regarding this
> subject was ignored?
> --
> Ole Bulbuk Tel.: 0331/74759/60
> Ernst Basler + Partner Fax: 0331/74759/90
> Tuchmacherstr. 47 E-Mail: mailto:ob@ebp.de
> 14482 Potsdam WWW: http://www.ebp.de
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
JGlobal Ltd.
http://www.jglobalonline.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Do you *really* not need localized exceptions?
Posted by Peter Donald <pe...@apache.org>.
On Wed, 24 Apr 2002 03:40, Ole Bulbuk wrote:
> I have noticed that there exists a package org.apache.avalon.excalibur.i18n
> that supports internationalization/localization. So I suppose somebody is
> using it.
A fair bit of the opensource stuff I do is i18ned (or will be over time) and I
have used localized exceptions in the past. As a matter of fact at one stage
I had extensions of all the standard exceptions. ie we had things like
LocalizedIllegalAccessException()
LocalizedIllegalStateException()
...
So I can see the need for it. However what I started doing after that was that
instead of putting localized string messages into the exception I ended up
putting error codes into the exceptions and putting special handling in my
log/error reporting routines.
So I can see a use. I guess I am wondering how you are going about doing it.
In our case we ended up with close to 300 cut-n-paste localized exception
classes which seems a bit excessive I guess ;)
> P.S.: Sorry for the eye-catching style but my last message regarding this
> subject was ignored?
Not ignored :) Just havent got around to replying ;)
--
Cheers,
Peter Donald
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Do you *really* not need localized exceptions?
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
Ole,
my answer to the question would be: "No. I do not need
localized Exceptions." Why?
The message in the exception does not always make sense to
the user, and is often very unhelpful and cryptic. It may
work some times, but then you have structured your entire
Exception hierarchy around your own application, with the
intent that they should be used to create messages on the
client side.
I prefer to keep Exceptions inside the application - when
an error condition is presented to the user, I want to
control how it is presented based on the current application
context.
The question is then: Do we *want* localized exception code
in Avalon? I'm 0 on that. I see no use for it, but I see
no great danger in admitting it, maybe in Excalibur/i18n.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>