You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Noel J. Bergman" <no...@devtech.com> on 2002/08/04 06:08:05 UTC
CommandMap for Handlers
I am proposing the inclusion of a CommandMap, which we can use in our
Handlers. A prototypical use of the command map would look like:
// initialize the command map
commands = new CommandMap(new CommandMap.Command()
{
public do(String command, String argument, String argument1)
{ // implementation of default command
}
});
commands.add(<command>, new CommandMap.Command()
{
public do(String command, String argument, String argument1)
{ // implementation of <command>
}
});
e.g.,
commands.add("USER", new CommandMap.Command()
{
});
commands.add("PASS", new CommandMap.Command()
{
});
Later, when we have a command, it is invoked as:
commands.do(command, argument, argument1);
This would simplify code, potentially speed up code, modularize the code,
improve readability, and allow us to add additional things to the
CommandMap.Command class such as stats, per command log strings, etc.
Comments?
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: CommandMap for Handlers
Posted by "Noel J. Bergman" <no...@devtech.com>.
My view is that the Method class is too heavyweight in most cases to expose
to normal client code (and developers). As for creating additional objects,
Method instances are objects, so instantiation still occurs. Furthermore,
you have to wrap your arguments to call Method.invoke(Object, Object[]), so
there is the additional instantiation of an Object array. So rather than
expose a naked Method instance, I'd just as soon have a more direct mapping.
My prototype looks like:
cmds.perform(name, argument-list);
cmds.watchPerform(timeout, name, argument-list);
In the case of our handlers, since all of the methods are of the form:
doX(String, String, String);
the HandlerCommandMap exposes exactly that interface.
Anyhow, we can beat this subject to death.
--- Noel
-----Original Message-----
From: Harmeet Bedi [mailto:harmeet@kodemuse.com]
Sent: Tuesday, August 06, 2002 21:36
To: James Developers List
Subject: Re: CommandMap for Handlers
From: "Noel J. Bergman" <no...@devtech.com>
> If I understood your point, the reflection idea can be built by adding a
> specialized subclass of my CommandMap with a method that populates the
A little more than that, methods can be treated as objects and a method can
invoked from another method based on reflection and command name. The idea
was to have the benfits of command map pattern, without any need of creating
additional objects.
so instead of
if ( command.equals("DATA") )
doData(arg1....)
else if ( command.equals("USER") )
doUSER(arg1....)
etc. etc.
do
----
Method cmd = methodMap.get(<command>);
cmd.invoke(this,< args..>);
---
methodMap can be built in static initializer or lazily built once, based on
class reflection.
Harmeet
----- Original Message -----
From: "Noel J. Bergman" <no...@devtech.com>
> I addressed the timeout handling addressed in a separate thread.
>
> If I understood your point, the reflection idea can be built by adding a
> specialized subclass of my CommandMap with a method that populates the
> command map with command objects based upon inspecting the class for
> methods matching a convention. The command objects would simply invoke
> the target method on the target object using the specified calling
convention.
>
> --- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: CommandMap for Handlers
Posted by Harmeet Bedi <ha...@kodemuse.com>.
From: "Noel J. Bergman" <no...@devtech.com>
> If I understood your point, the reflection idea can be built by adding a
> specialized subclass of my CommandMap with a method that populates the
A little more than that, methods can be treated as objects and a method can
invoked from another method based on reflection and command name. The idea
was to have the benfits of command map pattern, without any need of creating
additional objects.
so instead of
if ( command.equals("DATA") )
doData(arg1....)
else if ( command.equals("USER") )
doUSER(arg1....)
etc. etc.
do
----
Method cmd = methodMap.get(<command>);
cmd.invoke(this,< args..>);
---
methodMap can be built in static initializer or lazily built once, based on
class reflection.
Harmeet
----- Original Message -----
From: "Noel J. Bergman" <no...@devtech.com>
> I addressed the timeout handling addressed in a separate thread.
>
> If I understood your point, the reflection idea can be built by adding a
> specialized subclass of my CommandMap with a method that populates the
> command map with command objects based upon inspecting the class for
methods
> matching a convention. The command objects would simply invoke the target
> method on the target object using the specified calling convention.
>
> --- Noel
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: CommandMap for Handlers
Posted by "Noel J. Bergman" <no...@devtech.com>.
I addressed the timeout handling addressed in a separate thread.
If I understood your point, the reflection idea can be built by adding a
specialized subclass of my CommandMap with a method that populates the
command map with command objects based upon inspecting the class for methods
matching a convention. The command objects would simply invoke the target
method on the target object using the specified calling convention.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Handler timeout/trigger issues
Posted by "Noel J. Bergman" <no...@devtech.com>.
> BTW. More than a year back there were problems with Avalon
> PeriodicTimeTrigger. It was apparently fixed. Here was an
> alternate implementation submitted.
James uses DefaultTimeScheduler, as you can see from the assembly.xml file:
<block
class="org.apache.avalon.cornerstone.blocks.scheduler.DefaultTimeScheduler"
name="scheduler">
The problems reported by Shilpa Dalmia are current, and were discussed on
both this list and the Avalon list just a couple of months ago.
As for your scheduler, I checked the nighly build for Cornerstone. Your
code has never been adopted into the build. I spoke with Paul Hammant
today, who said that he'll take a look at it.
However, it does not appear to me that your code resolves the issue raised
by Shilpa. You do remove the task from your task map, but
TimerTask.cancel() simply marks the task as cancelled. There is still an
accummulation of TimerTask objects in the Timer's queue, which is the issue
being raised in the first place.
FWIW, you have a minor bug in your exception handling.
TimeSchedulerImpl.removeTrigger(String) is supposed to throw an exception,
but that code is only present in TimeSchedulerImpl.removeTrigger(String). I
believe that this would be correct:
private Task remove( String name )
throws NoSuchElementException
{
Task task = (Task)taskMap.remove(name);
if ( task == null )
throw new NoSuchElementException(name);
task.cancel();
return task;
}
public void removeTrigger( String name )
throws NoSuchElementException
{
remove(name);
}
public void resetTrigger( String name )
throws NoSuchElementException
{
Task task = remove(name);
addTrigger(name,task.trigger,task.target);
}
> How does [timeout handling] relate to CommandMap. They
> seem to be 2 topics, what is the association.
With my implementation of the CommandMap, you invoke a command through the
map. One of the methods for invoking a command supports a timeout. That
was the association. Even if we don't use the CommandMap, my approach for a
lightweight watchdog is probably something to adopt.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: CommandMap for Handlers
Posted by Harmeet Bedi <ha...@kodemuse.com>.
> I don't know what your command map proposal looked like,
I'll try to dig up the actual proposal. The mail archives don't seem
to be too old. I think command map is fine, and yes that was my
preference. One midway proposal was based on java
reflection. Basically a command callled DATA is used to resolve a
method call doDATA using reflection. The map of method/command name
would be cached, and therefore pretty efficient. Most of the scripting
langualge command handler, for example in Python use this approach. If
the reslove results are cached there is minimal overhead.
> Another benefit is that I have (hopefully) added efficient handling of
> timeouts on operations. Right now handlers use the Cornerstone scheduler;
> see:
How does this relate to CommandMap. They seem to be 2 topics, what is
the association.
BTW. More than a year back there were problems with Avalon
PeriodicTimeTrigger. It was apparently fixed. Here was an alternate
implementation submitted. The nice thing about the submitted
implementation was that it was based on JDK Timer API.
http://www.mail-archive.com/avalon-dev@jakarta.apache.org/msg00255/TimeSched
ulerImpl.java
The problem is described with a unit test is at:
http://www.mail-archive.com/avalon-dev@jakarta.apache.org/msg00254.html
Harmeet
----- Original Message -----
From: "Noel J. Bergman" <no...@devtech.com>
To: "James Developers List" <ja...@jakarta.apache.org>
Sent: Monday, August 05, 2002 1:19 PM
Subject: RE: CommandMap for Handlers
> So far your objection is the only one (at least for this go 'round), and
it
> sounds as if you were in favor of it in the first place. Several others
> have expressed an interest in using command maps.
>
> I don't know what your command map proposal looked like, but my approach
> uses inner classes, so that all of a handler's code can stay in one file.
> However, because the commands are classes, as handlers get larger sets of
> verbs (e.g., IMAP), only the classes for for active commands need to be
> loaded.
>
> Another benefit is that I have (hopefully) added efficient handling of
> timeouts on operations. Right now handlers use the Cornerstone scheduler;
> see:
>
> http://www.mail-archive.com/james-dev@jakarta.apache.org/msg02222.html
> http://www.mail-archive.com/james-dev@jakarta.apache.org/msg02219.html
>
> Even if we don't adopt command maps, we should do something about that
> issue.
>
> As you say, there are other benefits.
>
> --- Noel
>
> -----Original Message-----
> From: Harmeet Bedi [mailto:harmeet@kodemuse.com]
> Sent: Monday, August 05, 2002 16:39
> To: James Developers List
> Subject: Re: CommandMap for Handlers
>
>
> This was proposed earlier.
>
> The initial iteration was all the command handing in a single method.
> I had proposed 2 alternate ways - separate methods and command map
objects.
> The latter was vetoed out and I had refactored into separate methods and
> left it at that.
>
> I think command map is nice, there are good precedents for example the
Slide
> project uses this very cleanly to handle DAV HTTP extensions. There is
also
> lot of similarity between commands like HELO and EHLO that could be more
> cleanly expressed by inheritence.
>
> However, I am not sure if this is worth revisiting.. There will find a big
> explosion in the number of classes, without much gain.
>
> I would say -1, based on a path that has been discussed and picked.
>
> Harmeet
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: CommandMap for Handlers
Posted by "Noel J. Bergman" <no...@devtech.com>.
So far your objection is the only one (at least for this go 'round), and it
sounds as if you were in favor of it in the first place. Several others
have expressed an interest in using command maps.
I don't know what your command map proposal looked like, but my approach
uses inner classes, so that all of a handler's code can stay in one file.
However, because the commands are classes, as handlers get larger sets of
verbs (e.g., IMAP), only the classes for for active commands need to be
loaded.
Another benefit is that I have (hopefully) added efficient handling of
timeouts on operations. Right now handlers use the Cornerstone scheduler;
see:
http://www.mail-archive.com/james-dev@jakarta.apache.org/msg02222.html
http://www.mail-archive.com/james-dev@jakarta.apache.org/msg02219.html
Even if we don't adopt command maps, we should do something about that
issue.
As you say, there are other benefits.
--- Noel
-----Original Message-----
From: Harmeet Bedi [mailto:harmeet@kodemuse.com]
Sent: Monday, August 05, 2002 16:39
To: James Developers List
Subject: Re: CommandMap for Handlers
This was proposed earlier.
The initial iteration was all the command handing in a single method.
I had proposed 2 alternate ways - separate methods and command map objects.
The latter was vetoed out and I had refactored into separate methods and
left it at that.
I think command map is nice, there are good precedents for example the Slide
project uses this very cleanly to handle DAV HTTP extensions. There is also
lot of similarity between commands like HELO and EHLO that could be more
cleanly expressed by inheritence.
However, I am not sure if this is worth revisiting.. There will find a big
explosion in the number of classes, without much gain.
I would say -1, based on a path that has been discussed and picked.
Harmeet
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: CommandMap for Handlers
Posted by Harmeet Bedi <ha...@kodemuse.com>.
This was proposed earlier.
The initial iteration was all the command handing in a single method.
I had proposed 2 alternate ways - separate methods and command map objects.
The latter was vetoed out and I had refactored into separate methods and
left it at that.
I think command map is nice, there are good precedents for example the Slide
project uses this very cleanly to handle DAV HTTP extensions. There is also
lot of similarity between commands like HELO and EHLO that could be more
cleanly expressed by inheritence.
However, I am not sure if this is worth revisiting.. There will find a big
explosion in the number of classes, without much gain.
I would say -1, based on a path that has been discussed and picked.
Harmeet
----- Original Message -----
From: "Noel J. Bergman" <no...@devtech.com>
To: "James-Dev Mailing List" <ja...@jakarta.apache.org>
Sent: Saturday, August 03, 2002 9:08 PM
Subject: CommandMap for Handlers
> I am proposing the inclusion of a CommandMap, which we can use in our
> Handlers. A prototypical use of the command map would look like:
>
> // initialize the command map
> commands = new CommandMap(new CommandMap.Command()
> {
> public do(String command, String argument, String argument1)
> { // implementation of default command
> }
> });
> commands.add(<command>, new CommandMap.Command()
> {
> public do(String command, String argument, String argument1)
> { // implementation of <command>
> }
> });
>
> e.g.,
>
> commands.add("USER", new CommandMap.Command()
> {
> });
> commands.add("PASS", new CommandMap.Command()
> {
> });
>
> Later, when we have a command, it is invoked as:
>
> commands.do(command, argument, argument1);
>
> This would simplify code, potentially speed up code, modularize the code,
> improve readability, and allow us to add additional things to the
> CommandMap.Command class such as stats, per command log strings, etc.
>
> Comments?
>
> --- Noel
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>