You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Mark Womack <mw...@apache.org> on 2003/10/20 07:40:58 UTC
Plugins, Receivers, Watchdogs
I just checked in some changes for plugins that I have been meaning to do
for some time. Mainly, getting rid of the overriding of the equals() method
to determing if 2 instances of a plugin are equivalent. Doing this is not
so great and has implications to override hashCode(), which requires a lot
more work than it was worth. There is now an isEquivalent() method in the
Plugin interface that can be implemented to determine, to the degree the
developer wishes, if the plugins are equivalent. The PluginRegistry uses
this to determine if a plugin being started is equivalent to a plugin
already running. The idea is to maintain an already running plugin over
stopping it and starting the new one. This avoids losing events during the
inbetween time.
I am still in the process of learning Eclipse, so I have not had a chance to
run the limited plugin tests. They might fail. If so, I will fix the
problems.
I am going to start on some Watchdog stuff this week, and I plan to greatly
improve the test suites around plugins, receivers, and watchdogs as well.
Regarding Eclipse, I wish it would just let me edit java files and run ant
builds. That is all I really want. None of this other project crap.
-Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
Re: Plugins, Receivers, Watchdogs
Posted by Paul Smith <pa...@lawlex.com.au>.
On Mon, 2003-10-20 at 15:40, Mark Womack wrote:
> I just checked in some changes for plugins that I have been meaning to do
> for some time. Mainly, getting rid of the overriding of the equals() method
> to determing if 2 instances of a plugin are equivalent. Doing this is not
> so great and has implications to override hashCode(), which requires a lot
> more work than it was worth. There is now an isEquivalent() method in the
> Plugin interface that can be implemented to determine, to the degree the
> developer wishes, if the plugins are equivalent. The PluginRegistry uses
> this to determine if a plugin being started is equivalent to a plugin
> already running. The idea is to maintain an already running plugin over
> stopping it and starting the new one. This avoids losing events during the
> inbetween time.
>
+1, good move.
> I am still in the process of learning Eclipse, so I have not had a chance to
> run the limited plugin tests. They might fail. If so, I will fix the
> problems.
>
> Regarding Eclipse, I wish it would just let me edit java files and run ant
> builds. That is all I really want. None of this other project crap.
Mark, for testing purposes I just run Ant in a command line window. I
was also thinking of creating a sort-of-MegaTestSuite class that creates
a TestSuite object encapsulating the tests that are run in Ant so that
it can easily be run inside Eclipse.
Feel free to email me offline for any Eclipse questions, been using it
for quite a while now and loving it.
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
Re: Plugins, Receivers, Watchdogs
Posted by Mark Womack <mw...@apache.org>.
Hi Ceki,
Yes, I could just stick the current implementation of isEquivalent() into
equals(). I just spent time pulling it out of some implementations that had
equals(). But I don't like the requirement that hashCode() then be
re-implemented. Yes, one could create simple versions of hashCode(), but
the overall requirement gets too heavy weight for the simple task I want to
use equals/isEquivalent for. I have also decided to not re-use the
Comparable interface as well. I want to avoid the need to rank plugins > or
< than each other. The PluginRegistry just needs the ability to determine
if one plugin is the exact equivalent of another so that it can avoid
shutting down the running plugin (and avoid missing logging events). That's
all.
At first I thought overridding equals() was a good idea. But upon deeper
review it was too heavy weight.
sorry for delay in replying to you,
-Mark
----- Original Message -----
From: "Ceki Gülcü" <ce...@qos.ch>
To: "Log4J Developers List" <lo...@jakarta.apache.org>
Sent: Wednesday, October 22, 2003 5:32 AM
Subject: Re: Plugins, Receivers, Watchdogs
At 10:40 PM 10/19/2003 -0700, Mark Womack wrote:
>I just checked in some changes for plugins that I have been meaning to do
>for some time. Mainly, getting rid of the overriding of the equals()
method
>to determing if 2 instances of a plugin are equivalent. Doing this is not
>so great and has implications to override hashCode(), which requires a lot
>more work than it was worth. There is now an isEquivalent() method in the
>Plugin interface that can be implemented to determine, to the degree the
>developer wishes, if the plugins are equivalent. The PluginRegistry uses
>this to determine if a plugin being started is equivalent to a plugin
>already running. The idea is to maintain an already running plugin over
>stopping it and starting the new one. This avoids losing events during the
>inbetween time.
Mark, I might be missing the point but you probably can simply stick
your current implementation of isEquivalent() into equals.
Correctly implementing hashCode can be easy as :
public int hashCode() {
return 1; // any other constant would do as well
}
another implementation which returns the same hash code for all
instances of the same class.
public int hashCode() {
return this.getClass().hashCode();
}
The above is correct in the sense that it adheres to the hashCode
contract.
The general contract of hashCode is (from the javadocs for Object class):
1) Whenever it is invoked on the same object more than once during an
execution of a Java application, the hashCode method must consistently
return the same integer, provided no information used in equals
comparisons on the object is modified. This integer need not remain
consistent from one execution of an application to another execution
of the same application.
2) If two objects are equal according to the equals(Object) method,
then calling the hashCode method on each of the two objects must
produce the same integer result.
3) It is not required that if two objects are unequal according to the
equals(java.lang.Object) method, then calling the hashCode method on
each of the two objects must produce distinct integer
results. However, the programmer should be aware that producing
distinct integer results for unequal objects may improve the
performance of hashtables.
Item 3 says that although not optional, unequal objects *may* return the
same hashCode.
I hope you find the above helpful.
>-Mark
--
Ceki Gülcü
For log4j documentation consider "The complete log4j manual"
ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
import org.apache.Facetime;
ApacheCon US 2003, 18-21 November http://apachecon.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
Re: Plugins, Receivers, Watchdogs
Posted by Ceki Gülcü <ce...@qos.ch>.
At 10:40 PM 10/19/2003 -0700, Mark Womack wrote:
>I just checked in some changes for plugins that I have been meaning to do
>for some time. Mainly, getting rid of the overriding of the equals() method
>to determing if 2 instances of a plugin are equivalent. Doing this is not
>so great and has implications to override hashCode(), which requires a lot
>more work than it was worth. There is now an isEquivalent() method in the
>Plugin interface that can be implemented to determine, to the degree the
>developer wishes, if the plugins are equivalent. The PluginRegistry uses
>this to determine if a plugin being started is equivalent to a plugin
>already running. The idea is to maintain an already running plugin over
>stopping it and starting the new one. This avoids losing events during the
>inbetween time.
Mark, I might be missing the point but you probably can simply stick
your current implementation of isEquivalent() into equals.
Correctly implementing hashCode can be easy as :
public int hashCode() {
return 1; // any other constant would do as well
}
another implementation which returns the same hash code for all
instances of the same class.
public int hashCode() {
return this.getClass().hashCode();
}
The above is correct in the sense that it adheres to the hashCode
contract.
The general contract of hashCode is (from the javadocs for Object class):
1) Whenever it is invoked on the same object more than once during an
execution of a Java application, the hashCode method must consistently
return the same integer, provided no information used in equals
comparisons on the object is modified. This integer need not remain
consistent from one execution of an application to another execution
of the same application.
2) If two objects are equal according to the equals(Object) method,
then calling the hashCode method on each of the two objects must
produce the same integer result.
3) It is not required that if two objects are unequal according to the
equals(java.lang.Object) method, then calling the hashCode method on
each of the two objects must produce distinct integer
results. However, the programmer should be aware that producing
distinct integer results for unequal objects may improve the
performance of hashtables.
Item 3 says that although not optional, unequal objects *may* return the
same hashCode.
I hope you find the above helpful.
>-Mark
--
Ceki Gülcü
For log4j documentation consider "The complete log4j manual"
ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
import org.apache.Facetime;
ApacheCon US 2003, 18-21 November http://apachecon.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org