RE: Serious problem with MRUMap -- JCS LRU and MRUMap -- RE: [simplestore] enhancements (was: [simplestore] inital check in)
That sample is a piece of crap.
I use a custom made linked list and my Map entries point to the list
nodes. This way you get really good performance since you have a
direct reference to the node you want to remove.
In the Sun sample the mrulist.remove(fname); call has to iterate
trough the LinkedList until it finds the right node since fname
is not a reference to the node but a reference to a object being
held by the node.
Have fun,
Paulo Gaspar
-Original Message-
From: Aaron Smuts [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 31, 2002 6:24 AM
To: 'Jakarta Commons Developers List'
Subject: Serious problem with MRUMap -- JCS LRU and MRUMap -- RE:
[simplestore] enhancements (was: [simplestore] inital check in)
I found this example of a MRUCache on the sun site and tried making a
memory cache plugin with the technique.
http://developer.java.sun.com/developer/onlineTraining/Programming/JDCBo
ok/perf4.html
The performance of the LinkedList remove function makes it unusable.
They should deprecate it.
I'm going to check the code into JCS as an example. I got around the
remove problem for initial puts, since you can avoid a remove, but any
updates will kill you. Since every get in this system requires an
update of the linked list, it makes the technique unscalable.
The simplestore MRUMap class is pretty much the same as this example,
except it takes the remove hit for just about every operation, even an
initial put.
I've included some results and the main method I used to test the MRUMap
below. Just watch the performance degrade.
G:\dev\bin\classesjava MRUMap 1000 2
took 111 ms. to put 1000
took 170 ms. to get 1000
took 160 ms. to put 1000
took 150 ms. to get 1000
G:\dev\bin\classesjava MRUMap 2000 2
took 290 ms. to put 2000
took 891 ms. to get 2000
took 691 ms. to put 2000
took 711 ms. to get 2000
G:\dev\bin\classesjava MRUMap 3000 2
took 1272 ms. to put 3000
took 3365 ms. to get 3000
took 3165 ms. to put 3000
took 3645 ms. to get 3000
G:\dev\bin\classesjava MRUMap 5000 2
took 6389 ms. to put 5000
took 16665 ms. to get 5000
took 16764 ms. to put 5000
took 16885 ms. to get 5000
G:\dev\bin\classesjava MRUMap 9000 2
took 26779 ms. to put 9000
took 56403 ms. to get 9000
took 51044 ms. to put 9000
took 54429 ms. to get 9000
(Oh, I depackaged the MRUMap to make it easier to work with. I attached
it.)
The test method for MRUMap:
//
public static void main( String[] args ) {
int size = 1000;
if ( args.length 0 ) {
try {
size = Integer.parseInt(args[0]);
} catch ( NumberFormatException e ) {
System.out.println( arg 1 (size) should be a number );
}
}
int cycles = 2;
if ( args.length 1 ) {
try {
cycles = Integer.parseInt(args[1]);
} catch ( NumberFormatException e ) {
System.out.println( arg 2 (cycles) should be a number
);
}
}
MRUMap map = new MRUMap( size );
boolean show = false;
if ( args.length 2 ) {
try {
show = Boolean.valueOf(args[2]).booleanValue();;
} catch ( Exception e ) {
System.out.println( arg 3 (show) should be true or
false );
}
}
for ( int i = 0; i cycles; i++ ) {
long startP = System.currentTimeMillis();
for ( int j = 0; j = size; j++ ) {
map.put( key + j, value + j );
}
long endP = System.currentTimeMillis();
long deltaP = endP - startP;
System.out.println( took + deltaP + ms. to put + size
);
long startG = System.currentTimeMillis();
for ( int j = 0; j = size; j++ ) {
String val = (String)map.get( key + j );
if ( show ) {
System.out.println( val );
}
}
long endG = System.currentTimeMillis();
long deltaG = endG - startG;
System.out.println( took + deltaG + ms. to get + size
);
}
} // end main
\\\
The bad method in java.util.LinkedList
/
/**
* Removes the first occurrence of the specified element in this
list. If
* the list does not contain the element, it is unchanged. More
formally,
* removes the element with the lowest index tti/tt such that
* tt(o==null ? get(i)==null : o.equals(get(i)))/tt (if such an
* element exists).
*
* @param o element to be removed from this list, if present.
* @return tttrue/tt if the list
Re: [Logging] [VOTE-REDUX] Commons Logging 1.0 Release
Paulo Gaspar wrote: Well, we are deprecating that logger as it puts us (Velocity devs) into the position to have to support every possible app usage of log4j. The replacement just takes a category, so you can configure things in your app as you want (not hope that we provided the configuration options through our properties...) and then have Velocity log directly to that... Good move. That kind of logging config makes more sense on the application (or framework) level than on a library like Velocity. Another way of configure Velocity for log4j: 1 one common log4j.xml config file for the servlet engine - it's admin work to control log levels; 2 every app has its own prefix: 'example_app' for example app know, that this app prefix is 'example_app'; 3 Velocity (static initialization within every web-app) is configured to get from Runtime 'xx.app_name' (xx to avoid problems) key and call Category.getInstance(); with 'xx.app_name.velocity' within our LogSystem implementation. So we can configure different logging level for every application. One (big for me) problem is that log4j during initialization want to make instances of every renderers and layouts so I have to put them into the servlet engine CLASSPATH. Regards Tomasz Pik [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: (Betwixt) a task for a volunteer [Was Re: digester data to XML]
COOL! I'll look at this ! cheers, slawek --- robert burrell donkin [EMAIL PROTECTED] wrote: On Tuesday, January 29, 2002, at 09:40 PM, Slawek Zachcial wrote: Hi, Can you list some betwixt points to be done? Maybe I could help? ;-) hi any help would be greatly appreciated :) the best candidate for a nice independent task would be to add the XMLBeanInfo extension mechansim. here's a paragraph i've pulled from one of james's posts: I've been meaning to put an extension mechanism into XMLIntrospector that works like the extension mechanism in java.beans.Instropector. e.g. given a FooBean class it would look on the classpath for a FooBeanXMLBeanInfo class using the same Java beans mechanism. if you're not familiar with BeanInfo's then you'll need to look up the java beans specs. the idea is that programmers would be able to create XMLBeanInfo classes which allow the bean-xml mapping to be customized in the same way that standard bean introspection can be. if you fancy giving this a go then please get back and i'll try to give you whatever help i can. - robert -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] __ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Who Commits to What
Peter Donald wrote: If you want for Avalon to move all its components across then there is one thing that needs to be changed. Same thing as it was when Commons was incepted, same thing I have been saying for ages. If working with Avalon is not desired then nothing needs to be changed. Perhaps you've answered this before, and I've missed it, but how is commit and voting rights different in the Commons than on any large Jakarta subproject? I assume that an Avalon committer that has worked exclusively on Excalibur would have voting rights on the Framework too. Avalon is Avalon, a committer is a committer. We don't require the same degree of community behind every packgae in the Commons, because Committers to other Commons package can step up to bat if the usual developer is distracted. That's the way Meritocracy works. We watch each other's back. It's not your code, or my code, it's our code. When the code is donated to a subproject, all Committers to the subproject have equal responsiblity for its maintenance and continued deveopment. If it might fall to me to support something, then I should have a say over what I may need to support. Unilateral vetos only apply to product changes, and must be justifiable. You can't veto a release, or a plan, only real code or real documentation. A real veto must provide real alternatives or present real technical problems, or it is not justifiable. If you don't believe me, ask Brian or Roy. AFAIK, there is no precedent for saying a Committer to subproject can vote on this or that, but not on something else. Either the Commons is a subproject or it isn't. If we are going to change the voting rights in the Commons, then we should bite the bullet and propose it as a top-level ASF Project, and perhaps ask the XML Commons to join us. The Commons could then have its own PMC, and parcel out the commit and voting rights any way it saw fit. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Java Web Development with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Serious problem with MRUMap -- JCS LRU and MRUMap -- RE: [simplestore] enhancements (was: [simplestore] inital check in)
-Original Message-
From: Paulo Gaspar [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 31, 2002 6:14 AM
To: Jakarta Commons Developers List; [EMAIL PROTECTED]
Subject: RE: Serious problem with MRUMap -- JCS LRU and MRUMap -- RE:
[simplestore] enhancements (was: [simplestore] inital check in)
That sample is a piece of crap.
Sure is. O(N) performance.
I use a custom made linked list and my Map entries point to the list
nodes. This way you get really good performance since you have a
direct reference to the node you want to remove.
The LRUMemoryCache in JCS is like this. The memory elements are wrapped
by a descriptor that keeps track of the next and previous. The double
linked list performance is around O(1).
In the Sun sample the mrulist.remove(fname); call has to iterate
trough the LinkedList until it finds the right node since fname
is not a reference to the node but a reference to a object being
held by the node.
It is effectively just a Queue, which is not useful for this aspect of
cache management.
Aaron
Have fun,
Paulo Gaspar
-Original Message-
From: Aaron Smuts [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 31, 2002 6:24 AM
To: 'Jakarta Commons Developers List'
Subject: Serious problem with MRUMap -- JCS LRU and MRUMap -- RE:
[simplestore] enhancements (was: [simplestore] inital check in)
I found this example of a MRUCache on the sun site and tried making
a
memory cache plugin with the technique.
http://developer.java.sun.com/developer/onlineTraining/Programming/JDCBo
ok/perf4.html
The performance of the LinkedList remove function makes it unusable.
They should deprecate it.
I'm going to check the code into JCS as an example. I got around
the
remove problem for initial puts, since you can avoid a remove, but
any
updates will kill you. Since every get in this system requires an
update of the linked list, it makes the technique unscalable.
The simplestore MRUMap class is pretty much the same as this
example,
except it takes the remove hit for just about every operation, even
an
initial put.
I've included some results and the main method I used to test the
MRUMap
below. Just watch the performance degrade.
G:\dev\bin\classesjava MRUMap 1000 2
took 111 ms. to put 1000
took 170 ms. to get 1000
took 160 ms. to put 1000
took 150 ms. to get 1000
G:\dev\bin\classesjava MRUMap 2000 2
took 290 ms. to put 2000
took 891 ms. to get 2000
took 691 ms. to put 2000
took 711 ms. to get 2000
G:\dev\bin\classesjava MRUMap 3000 2
took 1272 ms. to put 3000
took 3365 ms. to get 3000
took 3165 ms. to put 3000
took 3645 ms. to get 3000
G:\dev\bin\classesjava MRUMap 5000 2
took 6389 ms. to put 5000
took 16665 ms. to get 5000
took 16764 ms. to put 5000
took 16885 ms. to get 5000
G:\dev\bin\classesjava MRUMap 9000 2
took 26779 ms. to put 9000
took 56403 ms. to get 9000
took 51044 ms. to put 9000
took 54429 ms. to get 9000
(Oh, I depackaged the MRUMap to make it easier to work with. I
attached
it.)
The test method for MRUMap:
//
public static void main( String[] args ) {
int size = 1000;
if ( args.length 0 ) {
try {
size = Integer.parseInt(args[0]);
} catch ( NumberFormatException e ) {
System.out.println( arg 1 (size) should be a
number );
}
}
int cycles = 2;
if ( args.length 1 ) {
try {
cycles = Integer.parseInt(args[1]);
} catch ( NumberFormatException e ) {
System.out.println( arg 2 (cycles) should be a
number
);
}
}
MRUMap map = new MRUMap( size );
boolean show = false;
if ( args.length 2 ) {
try {
show = Boolean.valueOf(args[2]).booleanValue();;
} catch ( Exception e ) {
System.out.println( arg 3 (show) should be true or
false );
}
}
for ( int i = 0; i cycles; i++ ) {
long startP = System.currentTimeMillis();
for ( int j = 0; j = size; j++ ) {
map.put( key + j, value + j );
}
long endP = System.currentTimeMillis();
long deltaP = endP - startP;
System.out.println( took + deltaP + ms. to put +
size
);
long startG = System.currentTimeMillis();
for ( int j = 0; j = size; j++ ) {
String val = (String)map.get( key + j );
if ( show ) {
System.out.println( val );
}
}
long endG = System.currentTimeMillis();
long deltaG = endG - startG;
RE: Serious problem with MRUMap -- JCS LRU and MRUMap -- RE: [simplestore] enhancements (was: [simplestore] inital check in)
-Original Message-
From: Juozas Baliuka [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 31, 2002 3:38 AM
To: Jakarta Commons Developers List
Subject: Re: Serious problem with MRUMap -- JCS LRU and MRUMap -- RE:
[simplestore] enhancements (was: [simplestore] inital check in)
Hi,
Yes this problem exits at this time, cache operations are
approximately
liner then we use lists for MRU stuf .
I am going to use SoftMemoryStore without Swap in current project ,
but
there are more projects and more specific problems. My problems are :
1)I can't lose object from cache if application has strong reference
on
it.
2)Memory is limited and need to remove object from cache if it is
unused
and old.
I believe it is possible to implement and have cache performance
equivalent
to map performance.
it seams SoftMemoryStore memory store solves my problem, but it is
not
well tested and I don't recommend
to use it in production at this time. I will use it on my own risk.
You should try to build it as a memory plugin for JCS. It might require
some element attribute additions (what type of reference) if they are
useful.
The cache hub manages expiration at request time, this could be moved to
a background thread. Cleanup of unused items could result in spooling.
JCS has a memory index of disk items. The performance is better than a
B tree, but it takes some memory (around 1.5 Mb for 500,000 items, not
much if you ask me.) There are also B tree disk plugins. . . . .
I believe everything can be optimized, and thank you for help.
At 12:23 AM 1/31/2002 -0500, you wrote:
I found this example of a MRUCache on the sun site and tried making a
memory cache plugin with the technique.
http://developer.java.sun.com/developer/onlineTraining/Programming/JDCB
o
ok/perf4.html
The performance of the LinkedList remove function makes it unusable.
They should deprecate it.
I'm going to check the code into JCS as an example. I got around the
remove problem for initial puts, since you can avoid a remove, but
any
updates will kill you. Since every get in this system requires an
update of the linked list, it makes the technique unscalable.
The simplestore MRUMap class is pretty much the same as this example,
except it takes the remove hit for just about every operation, even
an
initial put.
I've included some results and the main method I used to test the
MRUMap
below. Just watch the performance degrade.
G:\dev\bin\classesjava MRUMap 1000 2
took 111 ms. to put 1000
took 170 ms. to get 1000
took 160 ms. to put 1000
took 150 ms. to get 1000
G:\dev\bin\classesjava MRUMap 2000 2
took 290 ms. to put 2000
took 891 ms. to get 2000
took 691 ms. to put 2000
took 711 ms. to get 2000
G:\dev\bin\classesjava MRUMap 3000 2
took 1272 ms. to put 3000
took 3365 ms. to get 3000
took 3165 ms. to put 3000
took 3645 ms. to get 3000
G:\dev\bin\classesjava MRUMap 5000 2
took 6389 ms. to put 5000
took 16665 ms. to get 5000
took 16764 ms. to put 5000
took 16885 ms. to get 5000
G:\dev\bin\classesjava MRUMap 9000 2
took 26779 ms. to put 9000
took 56403 ms. to get 9000
took 51044 ms. to put 9000
took 54429 ms. to get 9000
(Oh, I depackaged the MRUMap to make it easier to work with. I
attached
it.)
The test method for MRUMap:
///
/
//
public static void main( String[] args ) {
int size = 1000;
if ( args.length 0 ) {
try {
size = Integer.parseInt(args[0]);
} catch ( NumberFormatException e ) {
System.out.println( arg 1 (size) should be a
number );
}
}
int cycles = 2;
if ( args.length 1 ) {
try {
cycles = Integer.parseInt(args[1]);
} catch ( NumberFormatException e ) {
System.out.println( arg 2 (cycles) should be a
number
);
}
}
MRUMap map = new MRUMap( size );
boolean show = false;
if ( args.length 2 ) {
try {
show = Boolean.valueOf(args[2]).booleanValue();;
} catch ( Exception e ) {
System.out.println( arg 3 (show) should be true or
false );
}
}
for ( int i = 0; i cycles; i++ ) {
long startP = System.currentTimeMillis();
for ( int j = 0; j = size; j++ ) {
map.put( key + j, value + j );
}
long endP = System.currentTimeMillis();
long deltaP = endP - startP;
System.out.println( took + deltaP + ms. to put +
size
);
long startG = System.currentTimeMillis();
for ( int j = 0; j = size; j++ ) {
String val = (String)map.get( key + j );
if ( show ) {
cvs commit: jakarta-commons/latka/xsl/site site.xsl
dion02/01/31 04:39:06 Modified:latka/xsl/site site.xsl Log: Latest version from site-2 Revision ChangesPath 1.3 +2 -1 jakarta-commons/latka/xsl/site/site.xsl Index: site.xsl === RCS file: /home/cvs/jakarta-commons/latka/xsl/site/site.xsl,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- site.xsl 23 Jan 2002 04:32:38 - 1.2 +++ site.xsl 31 Jan 2002 12:39:06 - 1.3 @@ -13,7 +13,7 @@ -- -!-- $Id: site.xsl,v 1.2 2002/01/23 04:32:38 dion Exp $ -- +!-- $Id: site.xsl,v 1.3 2002/01/31 12:39:06 dion Exp $ -- xsl:stylesheet xmlns:xsl=http://www.w3.org/1999/XSL/Transform; version=1.0 @@ -48,6 +48,7 @@ html head +xsl:apply-templates select=meta/ titlexsl:value-of select=$project/title/ - xsl:value-of select=properties/title//title xsl:for-each select=properties/author xsl:variable name=name -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Serious problem with MRUMap -- JCS LRU and MRUMap -- RE: [simplestore] enhancements (was: [simplestore] inital check in)
skip
You should try to build it as a memory plugin for JCS. It might require
some element attribute additions (what type of reference) if they are
useful.
The cache hub manages expiration at request time, this could be moved to
a background thread. Cleanup of unused items could result in spooling.
Sorry, I can't use any background cleanup it has no meaning for memory cache.
This thread can remove objects from cache, but not from memory, if
application has strong reference on object.
expiration at request time has no meaning if application has strong
reference on object.
example situation :
...
User u = cache.get(id);
if( u == null ){
u = User.create( id );
cache.put(id,u);
session.setAttribute(user,u);// I have strong reference here
team.add(u);
}
..
request.setAttribute(player,u);
...
Requests, operations , but I don't remove user from session
..
assertTrue(try to increase sessin time out, session.isValid() );
// my session is valid at this time.
// cache must not remove my user if GC not decided to do this.
assertEquals(cache doe's not work or bug in GC ,
session.getAttribute(user), cache.get(id));
Cache must release unused references, if memory is low and must never
remove object from cache if it used by application.
if this test fails I don't need this kind of cache, it can be very fast,
but not useful.
JCS has a memory index of disk items. The performance is better than a
B tree, but it takes some memory (around 1.5 Mb for 500,000 items, not
much if you ask me.) There are also B tree disk plugins. . . . .
I believe everything can be optimized, and thank you for help.
At 12:23 AM 1/31/2002 -0500, you wrote:
I found this example of a MRUCache on the sun site and tried making a
memory cache plugin with the technique.
http://developer.java.sun.com/developer/onlineTraining/Programming/JDCB
o
ok/perf4.html
The performance of the LinkedList remove function makes it unusable.
They should deprecate it.
I'm going to check the code into JCS as an example. I got around the
remove problem for initial puts, since you can avoid a remove, but
any
updates will kill you. Since every get in this system requires an
update of the linked list, it makes the technique unscalable.
The simplestore MRUMap class is pretty much the same as this example,
except it takes the remove hit for just about every operation, even
an
initial put.
I've included some results and the main method I used to test the
MRUMap
below. Just watch the performance degrade.
G:\dev\bin\classesjava MRUMap 1000 2
took 111 ms. to put 1000
took 170 ms. to get 1000
took 160 ms. to put 1000
took 150 ms. to get 1000
G:\dev\bin\classesjava MRUMap 2000 2
took 290 ms. to put 2000
took 891 ms. to get 2000
took 691 ms. to put 2000
took 711 ms. to get 2000
G:\dev\bin\classesjava MRUMap 3000 2
took 1272 ms. to put 3000
took 3365 ms. to get 3000
took 3165 ms. to put 3000
took 3645 ms. to get 3000
G:\dev\bin\classesjava MRUMap 5000 2
took 6389 ms. to put 5000
took 16665 ms. to get 5000
took 16764 ms. to put 5000
took 16885 ms. to get 5000
G:\dev\bin\classesjava MRUMap 9000 2
took 26779 ms. to put 9000
took 56403 ms. to get 9000
took 51044 ms. to put 9000
took 54429 ms. to get 9000
(Oh, I depackaged the MRUMap to make it easier to work with. I
attached
it.)
The test method for MRUMap:
///
/
//
public static void main( String[] args ) {
int size = 1000;
if ( args.length 0 ) {
try {
size = Integer.parseInt(args[0]);
} catch ( NumberFormatException e ) {
System.out.println( arg 1 (size) should be a
number );
}
}
int cycles = 2;
if ( args.length 1 ) {
try {
cycles = Integer.parseInt(args[1]);
} catch ( NumberFormatException e ) {
System.out.println( arg 2 (cycles) should be a
number
);
}
}
MRUMap map = new MRUMap( size );
boolean show = false;
if ( args.length 2 ) {
try {
show = Boolean.valueOf(args[2]).booleanValue();;
} catch ( Exception e ) {
System.out.println( arg 3 (show) should be true or
false );
}
}
for ( int i = 0; i cycles; i++ ) {
long startP = System.currentTimeMillis();
for ( int j = 0; j = size; j++ ) {
map.put( key + j, value + j );
}
long endP =
RE: Serious problem with MRUMap -- JCS LRU and MRUMap -- RE: [simplestore] enhancements (was: [simplestore] inital check in)
-Original Message-
From: Juozas Baliuka [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 31, 2002 12:23 PM
To: Jakarta Commons Developers List
Subject: RE: Serious problem with MRUMap -- JCS LRU and MRUMap -- RE:
[simplestore] enhancements (was: [simplestore] inital check in)
skip
You should try to build it as a memory plugin for JCS. It might require
some element attribute additions (what type of reference) if they are
useful.
The cache hub manages expiration at request time, this could be moved to
a background thread. Cleanup of unused items could result in spooling.
Sorry, I can't use any background cleanup it has no meaning for memory
cache.
Sure it does.
This thread can remove objects from cache, but not from memory, if
application has strong reference on object.
Yes. It can remove it from the cache.
expiration at request time has no meaning if application has strong
reference on object.
It can be removed from the cache.
example situation :
...
User u = cache.get(id);
if( u == null ){
u = User.create( id );
cache.put(id,u);
session.setAttribute(user,u);// I have strong reference here
team.add(u);
}
..
request.setAttribute(player,u);
...
Requests, operations , but I don't remove user from session
..
assertTrue(try to increase sessin time out, session.isValid() );
// my session is valid at this time.
// cache must not remove my user if GC not decided to do this.
assertEquals(cache doe's not work or bug in GC ,
session.getAttribute(user), cache.get(id));
Cache must release unused references, if memory is low and must never
remove object from cache if it used by application.
Why? Is it a cached store? It can be removed from the store.
I'm not sure what you are trying to do or why.
Good luck.
if this test fails I don't need this kind of cache, it can be very fast,
but not useful.
JCS has a memory index of disk items. The performance is better than a
B tree, but it takes some memory (around 1.5 Mb for 500,000 items, not
much if you ask me.) There are also B tree disk plugins. . . . .
I believe everything can be optimized, and thank you for help.
At 12:23 AM 1/31/2002 -0500, you wrote:
I found this example of a MRUCache on the sun site and tried making a
memory cache plugin with the technique.
http://developer.java.sun.com/developer/onlineTraining/Programming/JDCB
o
ok/perf4.html
The performance of the LinkedList remove function makes it unusable.
They should deprecate it.
I'm going to check the code into JCS as an example. I got around the
remove problem for initial puts, since you can avoid a remove, but
any
updates will kill you. Since every get in this system requires an
update of the linked list, it makes the technique unscalable.
The simplestore MRUMap class is pretty much the same as this example,
except it takes the remove hit for just about every operation, even
an
initial put.
I've included some results and the main method I used to test the
MRUMap
below. Just watch the performance degrade.
G:\dev\bin\classesjava MRUMap 1000 2
took 111 ms. to put 1000
took 170 ms. to get 1000
took 160 ms. to put 1000
took 150 ms. to get 1000
G:\dev\bin\classesjava MRUMap 2000 2
took 290 ms. to put 2000
took 891 ms. to get 2000
took 691 ms. to put 2000
took 711 ms. to get 2000
G:\dev\bin\classesjava MRUMap 3000 2
took 1272 ms. to put 3000
took 3365 ms. to get 3000
took 3165 ms. to put 3000
took 3645 ms. to get 3000
G:\dev\bin\classesjava MRUMap 5000 2
took 6389 ms. to put 5000
took 16665 ms. to get 5000
took 16764 ms. to put 5000
took 16885 ms. to get 5000
G:\dev\bin\classesjava MRUMap 9000 2
took 26779 ms. to put 9000
took 56403 ms. to get 9000
took 51044 ms. to put 9000
took 54429 ms. to get 9000
(Oh, I depackaged the MRUMap to make it easier to work with. I
attached
it.)
The test method for MRUMap:
///
/
//
public static void main( String[] args ) {
int size = 1000;
if ( args.length 0 ) {
try {
size = Integer.parseInt(args[0]);
} catch ( NumberFormatException e ) {
System.out.println( arg 1 (size) should be a
number );
}
}
int cycles = 2;
if ( args.length 1 ) {
try {
cycles = Integer.parseInt(args[1]);
} catch ( NumberFormatException e ) {
System.out.println( arg 2 (cycles) should be
RE: Serious problem with MRUMap -- JCS LRU and MRUMap -- RE: [si mplestore] enhancements (was: [simplestore] inital check in)
At 11:20 AM 1/31/2002 -0500, you wrote:
-Original Message-
From: Juozas Baliuka [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 31, 2002 12:23 PM
To: Jakarta Commons Developers List
Subject: RE: Serious problem with MRUMap -- JCS LRU and MRUMap -- RE:
[simplestore] enhancements (was: [simplestore] inital check in)
skip
You should try to build it as a memory plugin for JCS. It might require
some element attribute additions (what type of reference) if they are
useful.
The cache hub manages expiration at request time, this could be moved to
a background thread. Cleanup of unused items could result in spooling.
Sorry, I can't use any background cleanup it has no meaning for memory
cache.
Sure it does.
This thread can remove objects from cache, but not from memory, if
application has strong reference on object.
Yes. It can remove it from the cache.
expiration at request time has no meaning if application has strong
reference on object.
It can be removed from the cache.
example situation :
...
User u = cache.get(id);
if( u == null ){
u = User.create( id );
cache.put(id,u);
session.setAttribute(user,u);// I have strong reference here
team.add(u);
}
..
request.setAttribute(player,u);
...
Requests, operations , but I don't remove user from session
..
assertTrue(try to increase sessin time out, session.isValid() );
// my session is valid at this time.
// cache must not remove my user if GC not decided to do this.
assertEquals(cache doe's not work or bug in GC ,
session.getAttribute(user), cache.get(id));
Cache must release unused references, if memory is low and must never
remove object from cache if it used by application.
Why? Is it a cached store? It can be removed from the store.
I'm not sure what you are trying to do or why.
:) Yes, situation is trivial, but not trivial to understand me.
I need this for store close to JDO ideas :
Object obj = store.retrieveByID(id);
..
Any operations except store.remove(obj) or store.remove(MyClass,id) ;
if( store.retrieveByID(id) != obj)
throw new FatalException(my storage doe's not work);
Good luck.
if this test fails I don't need this kind of cache, it can be very fast,
but not useful.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/services/src/java/org/apache/commons/services Event.java EventModule.java EventRegistration.java Leaf.java Queue.java QueueModule.java Service.java ServiceManager.java ServiceModule.java
oalexeev02/01/31 08:57:45
Modified:services/src/java/org/apache/commons/services Event.java
EventModule.java EventRegistration.java Leaf.java
Queue.java QueueModule.java Service.java
ServiceManager.java ServiceModule.java
Log:
Change Digester related stuff.
Revision ChangesPath
1.3 +6 -1
jakarta-commons-sandbox/services/src/java/org/apache/commons/services/Event.java
Index: Event.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/services/src/java/org/apache/commons/services/Event.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- Event.java19 Dec 2001 16:21:28 - 1.2
+++ Event.java31 Jan 2002 16:57:44 - 1.3
@@ -10,7 +10,7 @@
/** Base class for all Events.
*
- * @version $Id: Event.java,v 1.2 2001/12/19 16:21:28 oalexeev Exp $
+ * @version $Id: Event.java,v 1.3 2002/01/31 16:57:44 oalexeev Exp $
* @author Oleg V Alexeev
*/
public class Event extends Leaf {
@@ -28,6 +28,11 @@
public void destroy() {
super.destroy();
eventRegistration = null;
+}
+
+public String toString() {
+return this.getClass().getName() + [eventRegistration=' +
+getEventRegistration() + '];
}
}
1.6 +13 -8
jakarta-commons-sandbox/services/src/java/org/apache/commons/services/EventModule.java
Index: EventModule.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/services/src/java/org/apache/commons/services/EventModule.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- EventModule.java 30 Jan 2002 09:26:02 - 1.5
+++ EventModule.java 31 Jan 2002 16:57:44 - 1.6
@@ -16,7 +16,7 @@
/** Event module. Generate events.
*
- * @version $Id: EventModule.java,v 1.5 2002/01/30 09:26:02 oalexeev Exp $
+ * @version $Id: EventModule.java,v 1.6 2002/01/31 16:57:44 oalexeev Exp $
* @author Oleg V Alexeev
*/
public class EventModule extends Module {
@@ -43,7 +43,9 @@
}
protected EventRegistration createDefaultEventRegistration() {
-return new EventRegistration();
+EventRegistration registration = new EventRegistration();
+registration.setType( org.apache.commons.services.Event );
+return registration;
}
public void addEventRegistration( EventRegistration eventRegistration ) {
@@ -61,6 +63,10 @@
pool.close();
}
+public EventRegistration getDefaultEventRegistration() {
+return defaultEventRegistration;
+}
+
public EventRegistration getEventRegistration( String key ) {
EventRegistration eventRegistration =
(EventRegistration)eventRegistrations.get( key );
if( eventRegistration==null ) {
@@ -69,11 +75,11 @@
return eventRegistration;
}
-public Event getEvent( String name ) throws Exception {
+public Event getEvent( String name ) {
return (Event)pool.borrowObject( name );
}
-public Event getDefaultEvent() throws Exception {
+public Event getDefaultEvent() {
return (Event)pool.borrowObject( defaultEventRegistration.getName()
);
}
@@ -83,11 +89,10 @@
throw new IllegalArgumentException( Module can not be used
alone. The path argument is mandatory. );
String eventPath =
-path + event;
+path + /event;
-digester.addRule( eventPath,
-new ObjectCreateRule( digester,
-org.apache.commons.services.EventRegistration, type ) );
+digester.addObjectCreate( eventPath,
org.apache.commons.services.EventRegistration,
+type );
digester.addSetNext( eventPath, addEventRegistration,
org.apache.commons.services.EventRegistration );
digester.addSetProperties( eventPath );
1.3 +6 -1
jakarta-commons-sandbox/services/src/java/org/apache/commons/services/EventRegistration.java
Index: EventRegistration.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/services/src/java/org/apache/commons/services/EventRegistration.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
---
RE: httpclient hangs indefinately
Well, since the con.open() method creates a new Socket object, it is subject
to the behavior of the Socket class. Unfortunately, at least as of 1.3,
attempting to create a new Socket to a host/port combo that does not answer
blocks indefinately (or at least for a very long time), this can't be
avoided directly. (It would be really nice if the JDK provided a Socket
constructor that took a timeout value to pass to the underlying OS). The
three ways I can think of to avoid it off hand are:
1. Implement a timeout mechanism outside of HttpClient with a
seperate thread that interrupts the connection attempts.
2. Implement a Socket object in the HttpClient framework that uses
this same sort of mechanism but hides the details behind the API
3. Use the 1.4 JDK and upgrade everything to use the new channels
API in non-blocking mode.
I wish there were a cleaner way. If anyone knows of one I'd love to hear
it.
-
John
-Original Message-
From: Allen, Michael B (RSCH) [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 30, 2002 10:50 PM
To: '[EMAIL PROTECTED]'
Subject: httpclient hangs indefinately
If I just use a simple test program like below and try to connect to certain
IP addresses that
are routable but don't have anything listing at the other end (returns
nothing, dead air), the
client hangs indefinately. Can anyone think of a solution to this problem?
Thanks,
Mike
import org.apache.commons.httpclient.*;
public class Test {
public static void main(String[] argv) throws Exception {
HttpConnection con = new HttpConnection( argv[0],
Integer.parseInt( argv[1] ));
con.open();
con.printLine( GET /index.html HTTP/1.0 );
con.printLine();
String s;
while(( s = con.readLine() ) != null ) {
System.out.println( s );
}
}
}
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Digester user question - How to use objects/parameters not in the body
Hopefully a quick question. Here's what I want to do: 1. Take an XML file 2. Use the digester to run through it, create an object and set a bunch of properties. 3. Then call a method in that object while passing in a Connection object. How do I do this? Is there a way to call a digester.addCallParam with a value that is not in the body of the XML? Do I have to push my Connection onto the stack to use it? If so, how do I do that?? Any help is appreciated, thanks. __ Kyle Robinson Systems Consultant Pangaea Systems Inc. (250) 360-0111
RE: Digester user question - How to use objects/parameters not in the body
To use any of the existing rules, your Connection would have to be on the stack. Use digester.push to do this before you call parse(). Note that this will make your Connection object the top object on the stack. Alternatively, just create your own rule class and then have it take your Connection as a parameter to set into the object. Does that help? Let me know if you need more, Scott Sanders -Original Message- From: Kyle Robinson [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 31, 2002 10:32 AM To: '[EMAIL PROTECTED]' Subject: Digester user question - How to use objects/parameters not in the body Hopefully a quick question. Here's what I want to do: 1. Take an XML file 2. Use the digester to run through it, create an object and set a bunch of properties. 3. Then call a method in that object while passing in a Connection object. How do I do this? Is there a way to call a digester.addCallParam with a value that is not in the body of the XML? Do I have to push my Connection onto the stack to use it? If so, how do I do that?? Any help is appreciated, thanks. __ Kyle Robinson Systems Consultant Pangaea Systems Inc. (250) 360-0111 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Digester user question - How to use objects/parameters not in the body
Yes, that helps. Thanks. I'll try it and let ya know. -Original Message- From: Scott Sanders [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 31, 2002 10:26 AM To: Jakarta Commons Developers List Subject: RE: Digester user question - How to use objects/parameters not in the body To use any of the existing rules, your Connection would have to be on the stack. Use digester.push to do this before you call parse(). Note that this will make your Connection object the top object on the stack. Alternatively, just create your own rule class and then have it take your Connection as a parameter to set into the object. Does that help? Let me know if you need more, Scott Sanders -Original Message- From: Kyle Robinson [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 31, 2002 10:32 AM To: '[EMAIL PROTECTED]' Subject: Digester user question - How to use objects/parameters not in the body Hopefully a quick question. Here's what I want to do: 1. Take an XML file 2. Use the digester to run through it, create an object and set a bunch of properties. 3. Then call a method in that object while passing in a Connection object. How do I do this? Is there a way to call a digester.addCallParam with a value that is not in the body of the XML? Do I have to push my Connection onto the stack to use it? If so, how do I do that?? Any help is appreciated, thanks. __ Kyle Robinson Systems Consultant Pangaea Systems Inc. (250) 360-0111 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: httpclient hangs indefinately
Incidentally, it doesn't actually hang indefinately, for me it looks like it
times out after about 3 minutes and 12 seconds.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 31, 2002 1:24 PM
To: [EMAIL PROTECTED]
Subject: RE: httpclient hangs indefinately
Well, since the con.open() method creates a new Socket object, it is subject
to the behavior of the Socket class. Unfortunately, at least as of 1.3,
attempting to create a new Socket to a host/port combo that does not answer
blocks indefinately (or at least for a very long time), this can't be
avoided directly. (It would be really nice if the JDK provided a Socket
constructor that took a timeout value to pass to the underlying OS). The
three ways I can think of to avoid it off hand are:
1. Implement a timeout mechanism outside of HttpClient with a
seperate thread that interrupts the connection attempts.
2. Implement a Socket object in the HttpClient framework that uses
this same sort of mechanism but hides the details behind the API
3. Use the 1.4 JDK and upgrade everything to use the new channels
API in non-blocking mode.
I wish there were a cleaner way. If anyone knows of one I'd love to hear
it.
-
John
-Original Message-
From: Allen, Michael B (RSCH) [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 30, 2002 10:50 PM
To: '[EMAIL PROTECTED]'
Subject: httpclient hangs indefinately
If I just use a simple test program like below and try to connect to certain
IP addresses that
are routable but don't have anything listing at the other end (returns
nothing, dead air), the
client hangs indefinately. Can anyone think of a solution to this problem?
Thanks,
Mike
import org.apache.commons.httpclient.*;
public class Test {
public static void main(String[] argv) throws Exception {
HttpConnection con = new HttpConnection( argv[0],
Integer.parseInt( argv[1] ));
con.open();
con.printLine( GET /index.html HTTP/1.0 );
con.printLine();
String s;
while(( s = con.readLine() ) != null ) {
System.out.println( s );
}
}
}
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[httpclient] volunteer for RFC 2109 support task
I sent a message to the list before which I got no response to so I'm trying again with perhaps a more descriptive subject line and as well am including more detail of my proposed solution. I am volunteering to take care of the task listed on the page at http://jakarta.apache.org/commons/httpclient/status.html which lists, as an action item: Cookie Ordering Per RFC 2109, the cookies returned in a Cookie header should be ordered so that the better matches (i.e., more specific path/domain) come first. Currently no effort is made to do that. I have actually already implemented a solution to this task. The solution consists of making the org.apache.commons.httpclient.Cookie object implement the Comparator interface to compare cookies in the proper order and then modifying the primary createCookieHeader() method to add the cookies to a TreeSet (which implements SortedSet) as it finds that they match, then retrieving them from the SortedSet in order to create the cookie header. The solution also adds a private static RuleBasedCollator to be used as a utility object by the compare method for comparison of domain names and paths when all else is equal. The solution consists of an 137-line patch to src/org/apache/commons/httpclient/Cookie.java. In addition I implemented a JUnit test to make sure that the comparisons are performed correctly. This consists of a 89-line patch to src/test/org/apache/commons/httpclient/TestCookie.java. Both patches are attached as the output of cvs diff -c file. If there's a particular format you'd like or options I should use with diff, let me know. If I'm posting this to the wrong place or this has already been fixed by someone else, also please let me know. Thanks, hope this helps, - John Cookie.patch Description: Binary data TestCookie.patch Description: Binary data -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: httpclient hangs indefinately
Hello,
This is a known issue, unfortunately.
I brought it up recently (mailing list archives?) after I saw the same problems as you
have.
I opted for your 3rd suggestion in my local version of HTTP Client.
It is too early to put that in the distributed version of HTTP Client for now.
As there is no intense development of HTTP Client that's worked fine for me.
I simply used the Socket's connect call with some timeout value.
Otis
On Thu, 31 January 2002, [EMAIL PROTECTED] wrote:
Well, since the con.open() method creates a new Socket object, it is subject
to the behavior of the Socket class. Unfortunately, at least as of 1.3,
attempting to create a new Socket to a host/port combo that does not answer
blocks indefinately (or at least for a very long time), this can't be
avoided directly. (It would be really nice if the JDK provided a Socket
constructor that took a timeout value to pass to the underlying OS). The
three ways I can think of to avoid it off hand are:
1. Implement a timeout mechanism outside of HttpClient with a
seperate thread that interrupts the connection attempts.
2. Implement a Socket object in the HttpClient framework that uses
this same sort of mechanism but hides the details behind the API
3. Use the 1.4 JDK and upgrade everything to use the new channels
API in non-blocking mode.
I wish there were a cleaner way. If anyone knows of one I'd love to hear
it.
-
John
-Original Message-
From: Allen, Michael B (RSCH) [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 30, 2002 10:50 PM
To: '[EMAIL PROTECTED]'
Subject: httpclient hangs indefinately
If I just use a simple test program like below and try to connect to certain
IP addresses that
are routable but don't have anything listing at the other end (returns
nothing, dead air), the
client hangs indefinately. Can anyone think of a solution to this problem?
Thanks,
Mike
import org.apache.commons.httpclient.*;
public class Test {
public static void main(String[] argv) throws Exception {
HttpConnection con = new HttpConnection( argv[0],
Integer.parseInt( argv[1] ));
con.open();
con.printLine( GET /index.html HTTP/1.0 );
con.printLine();
String s;
while(( s = con.readLine() ) != null ) {
System.out.println( s );
}
}
}
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
_
iVillage.com: Solutions for Your Life
Check out the most exciting women's community on the Web
http://www.ivillage.com
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/betwixt/src/test/org/apache/commons/betwixt/expression TestEvaluation.java
rdonkin 02/01/31 11:20:27
Modified:betwixt/src/java/org/apache/commons/betwixt/expression
Context.java
betwixt/src/test/org/apache/commons/betwixt/expression
TestEvaluation.java
Added: betwixt/src/java/org/apache/commons/betwixt/expression
CyclicReferenceException.java
Log:
newContext now throws an exception when the given bean is already in a parent context
Revision ChangesPath
1.5 +17 -7
jakarta-commons-sandbox/betwixt/src/java/org/apache/commons/betwixt/expression/Context.java
Index: Context.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/betwixt/src/java/org/apache/commons/betwixt/expression/Context.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- Context.java 30 Jan 2002 19:35:36 - 1.4
+++ Context.java 31 Jan 2002 19:20:27 - 1.5
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-commons-sandbox/betwixt/src/java/org/apache/commons/betwixt/expression/Context.java,v
1.4 2002/01/30 19:35:36 rdonkin Exp $
- * $Revision: 1.4 $
- * $Date: 2002/01/30 19:35:36 $
+ * $Header:
/home/cvs/jakarta-commons-sandbox/betwixt/src/java/org/apache/commons/betwixt/expression/Context.java,v
1.5 2002/01/31 19:20:27 rdonkin Exp $
+ * $Revision: 1.5 $
+ * $Date: 2002/01/31 19:20:27 $
*
*
*
@@ -56,7 +56,7 @@
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
- * $Id: Context.java,v 1.4 2002/01/30 19:35:36 rdonkin Exp $
+ * $Id: Context.java,v 1.5 2002/01/31 19:20:27 rdonkin Exp $
*/
package org.apache.commons.betwixt.expression;
@@ -86,7 +86,7 @@
* If the child is a parent then that operation fails. /p
*
* @author a href=mailto:[EMAIL PROTECTED];James Strachan/a
- * @version $Revision: 1.4 $
+ * @version $Revision: 1.5 $
*/
public class Context {
@@ -135,8 +135,18 @@
this.parent = parent;
}
-/** Returns a new child context with the given bean but the same log and
variables. */
-public Context newContext(Object newBean) {
+/** Returns a new child context with the given bean but the same log and
variables.
+ *
+ * @param newBean create a child context for this bean
+ * @throws CyclicReferenceException if the given bean is already in a parent
context
+ */
+public Context newContext(Object newBean) throws CyclicReferenceException {
+// first check that we aren't introducing a cycle
+if (isAncester(newBean)) {
+log.info(Found cyclic reference!);
+log.debug(newBean);
+throw new CyclicReferenceException();
+}
return new Context(newBean, variables, log, this);
}
1.1
jakarta-commons-sandbox/betwixt/src/java/org/apache/commons/betwixt/expression/CyclicReferenceException.java
Index: CyclicReferenceException.java
===
/*
* $Header:
/home/cvs/jakarta-commons-sandbox/betwixt/src/java/org/apache/commons/betwixt/expression/CyclicReferenceException.java,v
1.1 2002/01/31 19:20:27 rdonkin Exp $
* $Revision: 1.1 $
* $Date: 2002/01/31 19:20:27 $
*
*
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 1999-2002 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowlegement:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowlegement may appear in the software itself,
*if and wherever such third-party acknowlegements normally appear.
*
* 4. The names The Jakarta Project, Commons, and Apache Software
*Foundation must not be used to endorse or promote products derived
*from this software without
cvs commit: jakarta-commons-sandbox/util/src/test/org/apache/commons/util FastPropertyResourceBundle.test.conf FastPropertyResourceBundleTest.java
dlr 02/01/31 11:21:12
Added: util/src/test/org/apache/commons/util
FastPropertyResourceBundle.test.conf
FastPropertyResourceBundleTest.java
Log:
Test from leandro.
Revision ChangesPath
1.1
jakarta-commons-sandbox/util/src/test/org/apache/commons/util/FastPropertyResourceBundle.test.conf
Index: FastPropertyResourceBundle.test.conf
===
key1=value1
key2=value2
1.1
jakarta-commons-sandbox/util/src/test/org/apache/commons/util/FastPropertyResourceBundleTest.java
Index: FastPropertyResourceBundleTest.java
===
package org.apache.commons.util;
import junit.framework.TestCase;
import junit.framework.TestSuite;
import junit.framework.Test;
import junit.framework.Assert;
import java.io.InputStream;
import java.io.FileInputStream;
import java.util.Enumeration;
/**
* @author a href=mailto:[EMAIL PROTECTED];Leandro Rodrigo Saad Cruz/a
* @author a href=mailto:[EMAIL PROTECTED];Daniel Rall/a
*/
public class FastPropertyResourceBundleTest
extends TestCase
{
protected static final String RESOURCE_NAME =
org/apache/commons/util/FastPropertyResourceBundle.test.conf;
FastPropertyResourceBundle rb;
Object first;
Object second;
public FastPropertyResourceBundleTest(String name)
{
super(name);
}
protected void setUp()
throws Exception
{
ClassLoader loader = getClass().getClassLoader();
InputStream in = loader.getResourceAsStream(RESOURCE_NAME);
rb = new FastPropertyResourceBundle(in);
first = new String(value1);
second = new String(value2);
}
protected void tearDown()
{
}
public void testFileContents()
{
Assert.assertTrue(rb.getString(key1).equals(first));
Assert.assertTrue(!rb.getString(key1).equals(second));
Assert.assertTrue(rb.getString(key2).equals(second));
Assert.assertTrue(!rb.getString(key2).equals(first));
}
public void testCacheSize()
{
Enumeration enum = rb.getKeys();
int count = 0;
while(enum.hasMoreElements())
{
count++;
enum.nextElement();
}
Assert.assertTrue(2 == count);
}
public static Test suite()
{
return new TestSuite(FastPropertyResourceBundleTest.class);
}
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[logging] defaulting to SimpleLog?
I've been working with the logging component in the betwixt package. I noticed it currently defaults to NoOp if log4j or logkit or JDK1.4 are not on the classpath. Would it not be more useful to developers in general to default to SimpleLog with a brief logging level, like WARN or ERROR? Folks can always disable logging if they require. I don't think its that common a use case to not want any logging whatsoever. James _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[betwixt] various changes...
I've made a few changes to the betwixt package in the sandbox * used a neater Ant build file (from digester) which among other things makes better generation of cross-referenced javadoc as well as being much tidier. I've also added all the various sample programs and common test cases as targets * improved the documentation somewhat, including new dependencies and more descriptions in PROPOSAL.html and STATUS.html. Also added Robert as a committer and started work in an OVERVIEW.html. * added a sample program that uses the RSS sample from digester to autogenerate the XML representation of the RSS beans. As we explore customization of the generated XML format, we should be able to reorder rename elements and so forth to produce a valid RSS file from the beans. i.e. the RSS demo in digester is a good test case for betwixt. Adding support for DTD declarations sounds like a good idea also. * an early version of BeanReader which extends Digester and uses the XMLIntrospector to configure digester rules. This is extremely alpha and an experiment to see if the current guise of betwixt is capable of being bidrectional. Betwixt started life as being bean - XML so it could well need some refactoring to really do both ways around. Right now the XML - bean via digester is pretty crude - handling type conversions and collections/arrays/indexed properties needs serious attention James _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[logging] makeNewLogInstance() method...
The LogSource has a static factory method called makeNewLogInstance(); How about following the naming conventions of JAXP and other fairly recent libraries of just calling this newInstance()? Its not a big deal, it just seems a bit less of a mouthful to remember. Also a question. From the code it appears that the getInstance() method uses lazy construction and calls makeNewLogInstance() if one does not already exist. If so, should makeNewLogInstance() be a private/protected method? i.e. should users always just call getInstance(). Or to put that another way, when should users call makeNewLogInstance() over getInstance(). James _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [logging] makeNewLogInstance() method...
+1. Go for it. Scott -Original Message- From: James Strachan [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 31, 2002 11:16 AM To: Jakarta Commons Developers Subject: [logging] makeNewLogInstance() method... The LogSource has a static factory method called makeNewLogInstance(); How about following the naming conventions of JAXP and other fairly recent libraries of just calling this newInstance()? Its not a big deal, it just seems a bit less of a mouthful to remember. Also a question. From the code it appears that the getInstance() method uses lazy construction and calls makeNewLogInstance() if one does not already exist. If so, should makeNewLogInstance() be a private/protected method? i.e. should users always just call getInstance(). Or to put that another way, when should users call makeNewLogInstance() over getInstance(). James _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: mailto:commons-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [logging] defaulting to SimpleLog?
+0. I am fine with that, but I assume that Craig or Robert had a reason for NoOpLog being the default. I personally am fine with either, as I *always* set my Log ;-) Scott -Original Message- From: James Strachan [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 31, 2002 11:00 AM To: Jakarta Commons Developers Subject: [logging] defaulting to SimpleLog? I've been working with the logging component in the betwixt package. I noticed it currently defaults to NoOp if log4j or logkit or JDK1.4 are not on the classpath. Would it not be more useful to developers in general to default to SimpleLog with a brief logging level, like WARN or ERROR? Folks can always disable logging if they require. I don't think its that common a use case to not want any logging whatsoever. James _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: mailto:commons-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [betwixt] various changes...
drat! i didn't get this email until just after i'd just committed some changes - hope i didn't step on you toes... those changes all sounds good but have you committed them yet? (i'm a bit worried since i can't see them when i update using cvs) - robert On Thursday, January 31, 2002, at 07:14 PM, James Strachan wrote: I've made a few changes to the betwixt package in the sandbox * used a neater Ant build file (from digester) which among other things makes better generation of cross-referenced javadoc as well as being much tidier. I've also added all the various sample programs and common test cases as targets * improved the documentation somewhat, including new dependencies and more descriptions in PROPOSAL.html and STATUS.html. Also added Robert as a committer and started work in an OVERVIEW.html. * added a sample program that uses the RSS sample from digester to autogenerate the XML representation of the RSS beans. As we explore customization of the generated XML format, we should be able to reorder rename elements and so forth to produce a valid RSS file from the beans. i.e. the RSS demo in digester is a good test case for betwixt. Adding support for DTD declarations sounds like a good idea also. * an early version of BeanReader which extends Digester and uses the XMLIntrospector to configure digester rules. This is extremely alpha and an experiment to see if the current guise of betwixt is capable of being bidrectional. Betwixt started life as being bean - XML so it could well need some refactoring to really do both ways around. Right now the XML - bean via digester is pretty crude - handling type conversions and collections/arrays/indexed properties needs serious attention James _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]. org For additional commands, e-mail: mailto:[EMAIL PROTECTED]. org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [logging] defaulting to SimpleLog?
On Thursday, January 31, 2002, at 07:20 PM, Scott Sanders wrote: +0. I am fine with that, but I assume that Craig or Robert had a reason for NoOpLog being the default. I personally am fine with either, as I *always* set my Log ;-) i think that this was decided by rodney and morgan (the original creators) . - robert -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: httpclient hangs indefinately
Yes, that is some OS-dependent timeout value. 3 min. and 15 seconds or so on Linux,
some other timeout value on Winblows, etc.
Otis
On Thu, 31 January 2002, [EMAIL PROTECTED] wrote:
Incidentally, it doesn't actually hang indefinately, for me it looks like it
times out after about 3 minutes and 12 seconds.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 31, 2002 1:24 PM
To: [EMAIL PROTECTED]
Subject: RE: httpclient hangs indefinately
Well, since the con.open() method creates a new Socket object, it is subject
to the behavior of the Socket class. Unfortunately, at least as of 1.3,
attempting to create a new Socket to a host/port combo that does not answer
blocks indefinately (or at least for a very long time), this can't be
avoided directly. (It would be really nice if the JDK provided a Socket
constructor that took a timeout value to pass to the underlying OS). The
three ways I can think of to avoid it off hand are:
1. Implement a timeout mechanism outside of HttpClient with a
seperate thread that interrupts the connection attempts.
2. Implement a Socket object in the HttpClient framework that uses
this same sort of mechanism but hides the details behind the API
3. Use the 1.4 JDK and upgrade everything to use the new channels
API in non-blocking mode.
I wish there were a cleaner way. If anyone knows of one I'd love to hear
it.
-
John
-Original Message-
From: Allen, Michael B (RSCH) [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 30, 2002 10:50 PM
To: '[EMAIL PROTECTED]'
Subject: httpclient hangs indefinately
If I just use a simple test program like below and try to connect to certain
IP addresses that
are routable but don't have anything listing at the other end (returns
nothing, dead air), the
client hangs indefinately. Can anyone think of a solution to this problem?
Thanks,
Mike
import org.apache.commons.httpclient.*;
public class Test {
public static void main(String[] argv) throws Exception {
HttpConnection con = new HttpConnection( argv[0],
Integer.parseInt( argv[1] ));
con.open();
con.printLine( GET /index.html HTTP/1.0 );
con.printLine();
String s;
while(( s = con.readLine() ) != null ) {
System.out.println( s );
}
}
}
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
_
iVillage.com: Solutions for Your Life
Check out the most exciting women's community on the Web
http://www.ivillage.com
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/betwixt/src/test/org/apache/commons/betwixt RSSBeanWriter.java TestBeanReader.java customer.xml rss-example.xml AbstractTestCase.java SampleBeanWriter.java TestAll.java TestBeanWriter.java TestXMLIntrospector.java
jstrachan02/01/31 11:56:03 Modified:betwixt PROPOSAL.html STATUS.html build.xml betwixt/src/java/org/apache/commons/betwixt ElementDescriptor.java NodeDescriptor.java XMLIntrospector.java betwixt/src/java/org/apache/commons/betwixt/expression ConstantExpression.java Context.java EmptyExpression.java Expression.java IteratorExpression.java MethodExpression.java StringExpression.java VariableExpression.java betwixt/src/test/org/apache/commons/betwixt AbstractTestCase.java SampleBeanWriter.java TestAll.java TestBeanWriter.java TestXMLIntrospector.java Added: betwixt OVERVIEW.html betwixt/src/java/org/apache/commons/betwixt/expression MethodUpdater.java Updater.java betwixt/src/java/org/apache/commons/betwixt/io BeanCreateRule.java BeanReader.java betwixt/src/test/org/apache/commons/betwixt RSSBeanWriter.java TestBeanReader.java customer.xml rss-example.xml Log: Added a much cleaner build.xml file from commons-digester so that proper linked JavaDoc is used as well as being much tidier alround. Added more examples, such as the RSSBeanWriter example that demonstrates using Digester to parse XML and betwixt to write it back out again. This will give us a good test case to customize the output to match the ordering and naming of the DTD. Added alpha coding of a BeanReader which extends Digester and defaults the rules based on the XMLBeanInfo for registered bean classes. Finally improved documentation, added Robert as a committer and started an overview guide. Revision ChangesPath 1.3 +25 -10jakarta-commons-sandbox/betwixt/PROPOSAL.html Index: PROPOSAL.html === RCS file: /home/cvs/jakarta-commons-sandbox/betwixt/PROPOSAL.html,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- PROPOSAL.html 19 Dec 2001 20:07:19 - 1.2 +++ PROPOSAL.html 31 Jan 2002 19:56:02 - 1.3 @@ -10,9 +10,15 @@ h3(0) Rationale/h3 p - The Betwixt library provides an XML BeanInfo mechansim - for mapping beans to XML structures in a flexible way. -/p + The Betwixt library provides an XML introspection mechanism + for mapping beans to XML in a flexible way. It is implemented using an + XMLIntrospector and XMLBeanInfo classes which are similar to the standard + Introspector and BeanInfo from the Java Beans specification./p +p + Betwixt provides a way of turning beans into XML as well as automatically + generating digester rules in a way that can be customized on a per type + manner in the same way that the BeanInfo mechanism can be used to customize + the default introspection on a java object./p p The Betwixt library could be shared across various projects such as JXPath, Jaxen, domify and dom4j. @@ -26,12 +32,20 @@ h3(1.5) Interaction With Other Packages/h3 -pemBetwixt/em relies only on standard JDK 1.2 (or later) APIs for -production deployment. It utilizes the JUnit unit testing framework for -developing and executing unit tests, but this is of interest only to -developers of the component. Betwixt also currently uses -the Jakarta Commons Collections subproject. -Logging is provided by the Jakarta Commons Logging subproject. +pemBetwixt/em relies only on standard JDK 1.2 (or later) APIs for +production deployment. + +piBetwixt/i also currently uses the following packages from Jakarta +Commonsul + liCollections (1.1 or greater)/li + liLogging (1.0 or greater)/li + liBeanUtils (1.1 or greater)/li + liDigester (1.1 or greater)/li + /ul + +piBetwixt/i utilizes the JUnit unit testing framework for developing and +executing unit tests, but this is of interest only to developers of the +component. p No external configuration files are utilized. /p @@ -69,6 +83,7 @@ h3(4) Initial Committers/h3 ul liJames Strachan/li + liRobert Burrell Donkin/li /ul /body -/html +/html \ No newline at end of file 1.2 +41 -2 jakarta-commons-sandbox/betwixt/STATUS.html Index: STATUS.html === RCS file: /home/cvs/jakarta-commons-sandbox/betwixt/STATUS.html,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- STATUS.html 22 Aug 2001 12:25:01 - 1.1 +++ STATUS.html 31 Jan 2002 19:56:02 - 1.2 @@ -7,7 +7,7 @@ div
Re: (betwixt) work for a volunteer [was Re: digester data to XML]
Hi Robert - Original Message - From: robert burrell donkin [EMAIL PROTECTED] i still want to find a fix for that problem of circular references. i'd really like to see what you think about the solution i've started on. (don' t worry i haven't really done much work on it so it'll be no problem to back it out again.) i think that fundamentally any solution comes around to being able to find out which beans have been evaluated earlier (in the recursion) and not evaluating any bean which has been evaluated earlier in the recursion. it seems to me that the context is a good place to add new functionality since it can be shared between different output implementations (i'm still keen on that bean navigator you were talking about). so, the idea is that to store an (optional) parent context in context. when you're evaluating the next level in a recursion, rather than starting with a new context, you start with a child context of the current level - and you check that the bean you're about to recursively evaluate isn't already an ancester of the current context. Sounds the right approach to me. Maybe just a Set of all beans traversed would do, then as the bean tree is walked duplicates can be ignored. what do you think and should i hold off while you're looking at generating digester rulesets? Go for it - after the work I've done today (which didn't change things that much) we shouldn't tread on each others toes. Just as I was doing a commit I noticed my copy of the code was out of date, so we've maybe merged codebases already ;-) James _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [logging] defaulting to SimpleLog?
Maybe an option for what should be the second chance logger among those two? Have fun, Paulo Gaspar -Original Message- From: robert burrell donkin [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 31, 2002 8:35 PM To: Jakarta Commons Developers List Subject: Re: [logging] defaulting to SimpleLog? On Thursday, January 31, 2002, at 07:20 PM, Scott Sanders wrote: +0. I am fine with that, but I assume that Craig or Robert had a reason for NoOpLog being the default. I personally am fine with either, as I *always* set my Log ;-) i think that this was decided by rodney and morgan (the original creators) . - robert -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons/digester STATUS.html build.xml
rdonkin 02/01/31 12:25:11
Modified:digester STATUS.html build.xml
Log:
Updated java doc copyright date in build.xml
Revision ChangesPath
1.4 +2 -1 jakarta-commons/digester/STATUS.html
Index: STATUS.html
===
RCS file: /home/cvs/jakarta-commons/digester/STATUS.html,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- STATUS.html 23 Jan 2002 21:25:21 - 1.3
+++ STATUS.html 31 Jan 2002 20:25:11 - 1.4
@@ -7,7 +7,7 @@
div align=center
h1The Jakarta Commons emDigester/em Component/h1
-$Id: STATUS.html,v 1.3 2002/01/23 21:25:21 sanders Exp $br
+$Id: STATUS.html,v 1.4 2002/01/31 20:25:11 rdonkin Exp $br
a href=#Introduction[Introduction]/a
a href=#Dependencies[Dependencies]/a
a href=#Release Info[Release Info]/a
@@ -80,6 +80,7 @@
liRodney Waldhoff/li
lia href=mailto:[EMAIL PROTECTED];Scott Sanders/a/li
lia href=mailto:[EMAIL PROTECTED];Geir Magnusson Jr./a/li
+lia href=mailto:[EMAIL PROTECTED];Robert Burrell Donkin/a/li
/ul
a name=Action Items/a
1.20 +2 -2 jakarta-commons/digester/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-commons/digester/build.xml,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- build.xml 5 Jan 2002 00:34:46 - 1.19
+++ build.xml 31 Jan 2002 20:25:11 - 1.20
@@ -3,7 +3,7 @@
!--
Digester component of the Jakarta Commons Subproject
-$Id: build.xml,v 1.19 2002/01/05 00:34:46 craigmcc Exp $
+$Id: build.xml,v 1.20 2002/01/31 20:25:11 rdonkin Exp $
--
@@ -212,7 +212,7 @@
version=true
doctitle=lt;h1gt;${component.title}lt;/h1gt;
windowtitle=${component.title} (Version ${component.version})
- bottom=Copyright (c) 2001 - Apache Software Foundation
+ bottom=Copyright (c) 2001-2002 - Apache Software Foundation
link offline=true packagelistLoc=${commons-beanutils.api}
href=http://jakarta.apache.org/commons/beanutils/api//
link offline=true packagelistLoc=${commons-collections.api}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: (betwixt) work for a volunteer [was Re: digester data to XML]
On Thursday, January 31, 2002, at 07:56 PM, James Strachan wrote: Hi Robert - Original Message - From: robert burrell donkin [EMAIL PROTECTED] i still want to find a fix for that problem of circular references. i'd really like to see what you think about the solution i've started on. (don' t worry i haven't really done much work on it so it'll be no problem to back it out again.) i think that fundamentally any solution comes around to being able to find out which beans have been evaluated earlier (in the recursion) and not evaluating any bean which has been evaluated earlier in the recursion. it seems to me that the context is a good place to add new functionality since it can be shared between different output implementations (i'm still keen on that bean navigator you were talking about). so, the idea is that to store an (optional) parent context in context. when you're evaluating the next level in a recursion, rather than starting with a new context, you start with a child context of the current level - and you check that the bean you're about to recursively evaluate isn't already an ancester of the current context. Sounds the right approach to me. Maybe just a Set of all beans traversed would do, then as the bean tree is walked duplicates can be ignored. what do you think and should i hold off while you're looking at generating digester rulesets? Go for it - after the work I've done today (which didn't change things that much) we shouldn't tread on each others toes. Just as I was doing a commit I noticed my copy of the code was out of date, so we've maybe merged codebases already ;-) our emails keep crossing in the middle - but all's well that ends well! as luck would have it, i think that our codebases have merged without too many problems :) i'll hold off working on that cyclic bug for a while (maybe i'll have a think about (c) on your list since we've got a willing victim whose promised to do (b)) until i know that you're not making changes to the core. - robert -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[VOTE] New committer - Paulo Gaspar
Alright, Paulo has a big enough mouth, and he knows where all the good code is, can I have some +1's to get him in to make io, util, codec, threading, etc. happen. He was a huge help on logging, and other discussions that I cannot remember. He has quite an intimate knowledge of a lot of apache code (Avalon, Tomcat, etc), and I think he would be a great addition to the team. +1 here. Scott Sanders -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] New committer - Paulo Gaspar
+1 of course, he has a big mouth ;-) in avalon, too! Gerhard - That must be wonderful! I don't understand it at all. - -Original Message- From: Scott Sanders [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 31, 2002 9:30 PM To: [EMAIL PROTECTED] Subject: [VOTE] New committer - Paulo Gaspar Alright, Paulo has a big enough mouth, and he knows where all the good code is, can I have some +1's to get him in to make io, util, codec, threading, etc. happen. He was a huge help on logging, and other discussions that I cannot remember. He has quite an intimate knowledge of a lot of apache code (Avalon, Tomcat, etc), and I think he would be a great addition to the team. +1 here. Scott Sanders -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] New committer - Paulo Gaspar
+1 - robert On Thursday, January 31, 2002, at 08:30 PM, Scott Sanders wrote: Alright, Paulo has a big enough mouth, and he knows where all the good code is, can I have some +1's to get him in to make io, util, codec, threading, etc. happen. He was a huge help on logging, and other discussions that I cannot remember. He has quite an intimate knowledge of a lot of apache code (Avalon, Tomcat, etc), and I think he would be a great addition to the team. +1 here. Scott Sanders -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]. org For additional commands, e-mail: mailto:[EMAIL PROTECTED]. org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [Logging] [VOTE-REDUX] Commons Logging 1.0 Release
Sh*t Costin! I was completely convinced that the String argument was the way to go and you had to come up with a technical argument that really makes some sense! =:o/ Now I am divided again! You and your object (bean?) counter habit! =;o) Well, I guess that your arguments make a lot of sense for software where performance is critical. Now, since you are also a security freak (like Peter Donald) I have a (Devil's Advocate) question: - What is the way to avoid that a hostile logger accesses the objects that are passed to it? Anyway, me thinks that it is not so natural that a hostile logger creeps into a system. Not as natural as an hostile app in a web/app service provider scenario. Have fun, Paulo -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 31, 2002 10:53 PM To: Jakarta Commons Developers List Subject: Re: [Logging] [VOTE-REDUX] Commons Logging 1.0 Release On Wed, 30 Jan 2002, Craig R. McClanahan wrote: (3) Change the message argument type from Object to String A big -1. Object in the interface will allow loggers to provide 'render'-like capability. This would allow passing things like StringBuffer or Object[] - that can be recycled. Think about an access log file - this would require about 5-6 concatenations, etc. If some logger impl. doesn't provide 'renderer' - it'll still be useable by apps that do not need it. The reverse is not true - if the API uses Strings, apps will not be able to take advantage of advanced loggers. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [Logging] [VOTE-REDUX] Commons Logging 1.0 Release
On Fri, 1 Feb 2002, Paulo Gaspar wrote: Now, since you are also a security freak (like Peter Donald) I have a (Devil's Advocate) question: - What is the way to avoid that a hostile logger accesses the objects that are passed to it? I'll send a longer email with comments on the logger - makeNewLogInstance is _very_ bad, and I'm sure Peter will point this out very soon :-) ( Ceki fixed this problem in log4j with a 'guard', there are other ways ). In any case, if the application is not trusting the logger, it shouldn't send information to it or call it. If it's not trusting the logger - it can send Strings or other imutable objects. However the logger will probably have more permissions than the application ( file access to log dir, etc ), so it's the logger that has to be protected from bad apps, not the reverse. And the current impl. doesn't seem to do that. I'm also not sure I like the discovery and creation mechanism - I would rather have a mechanism similar with jaxp, which is more flexible than the current fixed set of Class.forName(). And I don't like the mixing of impl. and interfaces at all. Again, that's just a quick look, I have a bit to much work to do. Anyway, me thinks that it is not so natural that a hostile logger creeps into a system. Not as natural as an hostile app in a web/app service provider scenario. That's my view as well. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] New committer - Paulo Gaspar
On 1/31/02 4:37 PM, Paulo Gaspar [EMAIL PROTECTED] wrote: This one got me by surprise. I thought I would have to contribute more than the couple of patches I did before. Nope. Anyway, everything is upside down: - I am being nominated committer at the commons without being committer elsewhere...; Not required. We know you are 'with the band'. - ...and my direct chief just gave informal authorization to contribute my common code AFTER I told him (via Instant Messaging) I was being voted. That's enough! Just apologize later if anything goes wrong... Now, I am not bribing you: I think the authorization sticks even if I end up getting a negative vote. Looks like you are in - not a worry. I also think that the reason he gave me that authorization has more to do with a small demo he finally got today. Maybe before he was wondering if all these mailing lists weren't just consuming my time. (Strange ideas he has!) Seem to consume a fair bit of my time... -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting POC lives! -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] New committer - Paulo Gaspar
I also think that the reason he gave me that authorization has more to do with a small demo he finally got today. Maybe before he was wondering if all these mailing lists weren't just consuming my time. (Strange ideas he has!) Seem to consume a fair bit of my time... Not enough, man ;-) Where's JJAR? :) Scott -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] New committer - Paulo Gaspar
Craig, Can you get Paulo set up? Or can I do it, and how? Scott -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 31, 2002 3:43 PM To: Jakarta Commons Developers List Subject: Re: [VOTE] New committer - Paulo Gaspar On 1/31/02 3:30 PM, Scott Sanders [EMAIL PROTECTED] wrote: Alright, Paulo has a big enough mouth, and he knows where all the good code is, can I have some +1's to get him in to make io, util, codec, threading, etc. happen. He was a huge help on logging, and other discussions that I cannot remember. He has quite an intimate knowledge of a lot of apache code (Avalon, Tomcat, etc), and I think he would be a great addition to the team. +1 here. Now he can show us his logging stuff :) -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Now what do we do? -- To unsubscribe, e-mail: mailto:commons-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/altrmi/src/java/org/apache/commons/altrmi/test TestClient.java TestInterface.java TestInterfaceImpl.java
hammant 02/01/31 16:16:38
Modified:altrmi/src/java/org/apache/commons/altrmi/client/impl
AbstractAltrmiFactory.java BaseServedObject.java
ServerClassAltrmiFactory.java
altrmi/src/java/org/apache/commons/altrmi/common
AltrmiReply.java MethodFacadeRequest.java
altrmi/src/java/org/apache/commons/altrmi/generator
ProxyGeneratorImpl.java
altrmi/src/java/org/apache/commons/altrmi/server/impl
DefaultMethodInvocationHandler.java
altrmi/src/java/org/apache/commons/altrmi/server/impl/adapters
InovcationHandlerAdapter.java
altrmi/src/java/org/apache/commons/altrmi/test
TestClient.java TestInterface.java
TestInterfaceImpl.java
Added: altrmi/src/java/org/apache/commons/altrmi/client
AltrmiProxy.java
altrmi/src/java/org/apache/commons/altrmi/common
MethodFacadeArrayReply.java
Log:
alternate facades can be arrays in return types
Revision ChangesPath
1.1
jakarta-commons-sandbox/altrmi/src/java/org/apache/commons/altrmi/client/AltrmiProxy.java
Index: AltrmiProxy.java
===
/*
* Copyright (C) The Apache Software Foundation. All rights reserved.
*
* This software is published under the terms of the Apache Software License
* version 1.1, a copy of which has been included with this distribution in
* the LICENSE.txt file.
*/
package org.apache.commons.altrmi.client;
/**
* Interface AltrmiProxy
*
*
* @author Paul Hammant a
href=mailto:[EMAIL PROTECTED];[EMAIL PROTECTED]/a
* @version $Revision: 1.1 $
*/
public interface AltrmiProxy {
}
1.12 +2 -14
jakarta-commons-sandbox/altrmi/src/java/org/apache/commons/altrmi/client/impl/AbstractAltrmiFactory.java
Index: AbstractAltrmiFactory.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/altrmi/src/java/org/apache/commons/altrmi/client/impl/AbstractAltrmiFactory.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- AbstractAltrmiFactory.java30 Jan 2002 23:42:44 - 1.11
+++ AbstractAltrmiFactory.java1 Feb 2002 00:16:38 - 1.12
@@ -31,7 +31,7 @@
*
*
* @author Paul Hammant a
href=mailto:[EMAIL PROTECTED];[EMAIL PROTECTED]/a
- * @version $Revision: 1.11 $
+ * @version $Revision: 1.12 $
*/
public abstract class AbstractAltrmiFactory implements AltrmiFactory {
@@ -48,6 +48,7 @@
*
*
* @param beanOnly
+ * @param classLoader
*
*/
public AbstractAltrmiFactory(boolean beanOnly, ClassLoader classLoader) {
@@ -95,19 +96,6 @@
}
}
-/**
- * Method getInstance
- *
- *
- * @param publishedServiceName
- * @param String objectName
- * @param BaseServedObject baseServedObject
- *
- * @return
- *
- * @throws AltrmiConnectionException
- *
- */
protected abstract Object getInstance(
String publishedServiceName, String objectName, BaseServedObject
baseServedObject,
boolean beanOnly) throws AltrmiConnectionException;
1.7 +47 -4
jakarta-commons-sandbox/altrmi/src/java/org/apache/commons/altrmi/client/impl/BaseServedObject.java
Index: BaseServedObject.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/altrmi/src/java/org/apache/commons/altrmi/client/impl/BaseServedObject.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- BaseServedObject.java 17 Jan 2002 12:14:28 - 1.6
+++ BaseServedObject.java 1 Feb 2002 00:16:38 - 1.7
@@ -20,6 +20,9 @@
import org.apache.commons.altrmi.common.MethodFacadeReply;
import org.apache.commons.altrmi.common.MethodFacadeRequest;
import org.apache.commons.altrmi.common.FacadeRefHolder;
+import org.apache.commons.altrmi.common.MethodFacadeArrayReply;
+
+import java.lang.reflect.Array;
/**
@@ -27,7 +30,7 @@
*
*
* @author Paul Hammant a
href=mailto:[EMAIL PROTECTED];[EMAIL PROTECTED]/a
- * @version $Revision: 1.6 $
+ * @version $Revision: 1.7 $
*/
public final class BaseServedObject {
@@ -90,9 +93,21 @@
public Object altrmiProcessObjectRequestGettingFacade(
String methodSignature, Object[] args, String objectName) throws
Throwable {
-MethodFacadeRequest request = new
MethodFacadeRequest(mPublishedServiceName, mObjectName,
-
cvs commit: jakarta-commons-sandbox/altrmi build.xml tests.xml
hammant 02/01/31 16:17:00
Modified:altrmi build.xml tests.xml
Log:
alternate facades can be arrays in return types
Revision ChangesPath
1.7 +6 -4 jakarta-commons-sandbox/altrmi/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-commons-sandbox/altrmi/build.xml,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- build.xml 30 Jan 2002 23:42:44 - 1.6
+++ build.xml 1 Feb 2002 00:17:00 - 1.7
@@ -3,7 +3,7 @@
!--
Alternative (to) RMI component of the Jakarta Commons Subproject
-$Id: build.xml,v 1.6 2002/01/30 23:42:44 hammant Exp $
+$Id: build.xml,v 1.7 2002/02/01 00:17:00 hammant Exp $
--
@@ -177,8 +177,7 @@
/target
- target name=dist depends=compile,javadoc
- description=Create binary distribution
+ target name=jars depends=compile
mkdir dir=${dist.home}/
copy file=../LICENSE
todir=${dist.home}/
@@ -222,5 +221,8 @@
/jar
/target
-
+
+ target name=dist depends=jars, javadoc
+ description=Create binary distribution
+ /target
/project
1.6 +2 -4 jakarta-commons-sandbox/altrmi/tests.xml
Index: tests.xml
===
RCS file: /home/cvs/jakarta-commons-sandbox/altrmi/tests.xml,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- tests.xml 28 Jan 2002 10:27:06 - 1.5
+++ tests.xml 1 Feb 2002 00:17:00 - 1.6
@@ -3,7 +3,7 @@
!--
Alt (to) RMI component of the Jakarta Commons Subproject
-$Id: tests.xml,v 1.5 2002/01/28 10:27:06 hammant Exp $
+$Id: tests.xml,v 1.6 2002/02/01 00:17:00 hammant Exp $
--
@@ -231,9 +231,7 @@
/target
target name=pipedc depends=generate
-
-echoee ${java.home}/echo
-
+
java classname=org.apache.commons.altrmi.test.PipeTest fork=true
classpath refid=testC1.classpath/
arg value=D/
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] New committer - Paulo Gaspar
Don't spoil my drama! =;o) Paulo -Original Message- From: Scott Sanders [mailto:[EMAIL PROTECTED]] Sent: Friday, February 01, 2002 12:13 AM To: Jakarta Commons Developers List Subject: RE: [VOTE] New committer - Paulo Gaspar I don't see how that would depress you. You have contributed a lot, even without being a committer. Now, instead of just pointing to all the cool code out there, you can go get it and bring it to the fold. And there's no gamble about it, I will get some rest at least for a week or two ;-) Scott -Original Message- From: Paulo Gaspar [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 31, 2002 3:16 PM To: Jakarta Commons Developers List Subject: RE: [VOTE] New committer - Paulo Gaspar All this suggestions that I bigmouthed my way into becoming a committer depress me! =;o) This is the ultimate psychological gamble - pushing me into put code instead of words just to have some rest!!! I will try my best at contributing both. Thanks (I guess) and have fun, Paulo Gaspar -Original Message- From: Scott Sanders [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 31, 2002 10:27 PM To: Jakarta Commons Developers List Subject: RE: [VOTE] New committer - Paulo Gaspar Welcome aboard Paulo. Scott -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 31, 2002 1:30 PM To: Jakarta Commons Developers List Subject: Re: [VOTE] New committer - Paulo Gaspar +1 I think the idea is let you commit more code, and spend less time lobbying (so you can in turn commit more code, or at least more time working). Typically, committers are nominated along with a new package, but I don't see this as a requirement. I don't see that we could give a developer access to the sandbox, but the Commons Proper is a subproject like any other, and can elect whatever committer it likes. Paulo Gaspar wrote: This one got me by surprise. I thought I would have to contribute more than the couple of patches I did before. Anyway, everything is upside down: - I am being nominated committer at the commons without being committer elsewhere...; - ...and my direct chief just gave informal authorization to contribute my common code AFTER I told him (via Instant Messaging) I was being voted. Now, I am not bribing you: I think the authorization sticks even if I end up getting a negative vote. I also think that the reason he gave me that authorization has more to do with a small demo he finally got today. Maybe before he was wondering if all these mailing lists weren't just consuming my time. (Strange ideas he has!) =;o) Have fun, Paulo Gaspar -Original Message- From: Scott Sanders [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 31, 2002 9:30 PM To: [EMAIL PROTECTED] Subject: [VOTE] New committer - Paulo Gaspar Alright, Paulo has a big enough mouth, and he knows where all the good code is, can I have some +1's to get him in to make io, util, codec, threading, etc. happen. He was a huge help on logging, and other discussions that I cannot remember. He has quite an intimate knowledge of a lot of apache code (Avalon, Tomcat, etc), and I think he would be a great addition to the team. +1 here. Scott Sanders -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:commons-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Ted Husted, Husted dot Com, Fairport NY USA. -- Java Web Development with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ -- To unsubscribe, e-mail: mailto:commons-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:commons-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] New committer - Paulo Gaspar
Answer inline: -Original Message- From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED]] Sent: Friday, February 01, 2002 12:19 AM To: 'Jakarta Commons Developers List'; '[EMAIL PROTECTED]' Subject: RE: [VOTE] New committer - Paulo Gaspar First of all +1 for Paulo as Committer, we all can try to be users of his work, and try make him eat his own dog food.. :)) See? Another +1 with a revenge! =;o) De: Paulo Gaspar [mailto:[EMAIL PROTECTED]] Enviado el: viernes 1 de febrero de 2002 0:16 This is the ultimate psychological gamble - pushing me into put code instead of words just to have some rest!!! LOL ( please please i dont undertstand how you guys keep in pace with your work and jakarta mail list, writing messages and code at this rate.. overhelming!!! :))) Ask my girl friend! =:o/ Saludos , Ignacio J. Ortega Have fun, Paulo -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] New committer - Paulo Gaspar
Well... paulo if there is no other one. =:o) Thanks Sam, Paulo -Original Message- From: Sam Ruby [mailto:[EMAIL PROTECTED]] Sent: Friday, February 01, 2002 1:02 AM To: Jakarta Commons Developers List Subject: RE: [VOTE] New committer - Paulo Gaspar Scott Sanders wrote: Can you get Paulo set up? Or can I do it, and how? I'll take this one... Paulo what would you like your id to be? - Sam Ruby -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] New committer - Paulo Gaspar
LOL Do not encourage me! =:o) Have fun, Paulo -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Sent: Friday, February 01, 2002 12:56 AM To: Jakarta Commons Developers List; [EMAIL PROTECTED] Subject: Re: [VOTE] New committer - Paulo Gaspar +1 for Paulo too. All this suggestions that I bigmouthed my way into becoming a committer depress me! =;o) Well, obviously, you're not getting in because you're quiet ;-) Lol. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Request for a new Apache IDs
Thanks Sam, Paulo -Original Message- From: Sam Ruby [mailto:[EMAIL PROTECTED]] Sent: Friday, February 01, 2002 1:35 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Request for a new Apache IDs Please create the following new Apache ID: id: paulo name: Paulo Gaspar send password to: [EMAIL PROTECTED] group: apcvs, jakarta Thanks! - Sam Ruby -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[pool] interface additions/changes
I'd like to make a couple of suggestions for the Pool project: 1) Marker interface for poolKeys (for the KeyedPools) 2) The interface to borrow from a pool should throw a checked exception, returning to a pool should not. I'd be happy to provide patches should it be required. Keep up the good work! steve. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Request for a new Apache IDs
Thanks Manoj, Paulo -Original Message- From: Manoj Kasichainula [mailto:[EMAIL PROTECTED]] Sent: Friday, February 01, 2002 3:25 AM To: Sam Ruby Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Request for a new Apache IDs On Thu, Jan 31, 2002 at 07:34:41PM -0500, Sam Ruby wrote: Please create the following new Apache ID: id: paulo done -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Request for a new Apache IDs
On Thu, Jan 31, 2002 at 07:34:41PM -0500, Sam Ruby wrote: Please create the following new Apache ID: id: paulo done -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Serious problem with MRUMap -- JCS LRU and MRUMap -- FW: cvs commit: jakarta-turbine-stratum/src/java/org/apache/stratum/util/lru LRUStore.java LRUElementDescriptor.java LRUElement.java ILRUElement.java
I added a better map storage to stratum.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 31, 2002 10:56 PM
To: [EMAIL PROTECTED]
Subject: cvs commit:
jakarta-turbine-stratum/src/java/org/apache/stratum/util/lru
LRUStore.java LRUElementDescriptor.java LRUElement.java ILRUElement.java
asmuts 02/01/31 19:55:54
Added: src/java/org/apache/stratum/util/lru LRUStore.java
LRUElementDescriptor.java LRUElement.java
ILRUElement.java
Log:
Added this LRUStore pulled form JCS so it can be used by other
programs.
Not sure this is where it belongs, but it can be moved. It has O(1)
performance degredation and doesn't suffer from the O(N) limitations of
the LinkedList LRU implementations.
It comes with a partial removal and a waterfall method. it can be
overridden and so can the element wrapper, so the system is extendable.
you could extend the wrapper, override the put and use the
get(key,container) to get the wrapper if it had more info.
Revision ChangesPath
1.1
jakarta-turbine-stratum/src/java/org/apache/stratum/util/lru/LRUStore.ja
va
Index: LRUStore.java
===
package org.apache.stratum.util.lru;
import java.io.IOException;
import java.io.Serializable;
import java.util.HashMap;
import java.util.Hashtable;
import java.util.Iterator;
import java.util.Map;
import java.util.Set;
import java.util.Map.Entry;
import org.apache.stratum.util.lru.LRUElementDescriptor;
/
/**
* Example LRU program with O(1) performance degredation. Partial
removal has
* O(N) performance. A fast reference management system. The least
recently
* used items move to the end of the list and get waterfalled.
*
* Pulled from JCS project. Based on several generic algorithm book
examples.
*
*@author asmuts
*@createdJanuary 31, 2002
*/
public class LRUStore implements Serializable
{
private final static boolean debugcmd = false;
// removal
private final static boolean debugR = false;
//true;
private final static String NAME_COMPONENT_DELIMITER = :;
/**
* Description of the Field
*/
protected Map map = new Hashtable();
// LRU double linked list
private LRUElementDescriptor first;
private LRUElementDescriptor last;
private int max = 1000;
// make configurable
private int chunkSize = 5;
// for reflection
/**
* Constructor for the LRUStore object
*/
public LRUStore()
{
// might want to consider this an error state
//status = this.STATUS_ERROR;
}
// should use this method
/**
* Constructor for the LRUStore object
*
*@param max Description of the Parameter
*/
public LRUStore( int max )
{
initialize( max );
}
// for post reflection creation initialization
/**
* Description of the Method
*
*@param max Maximum number of elements in LRUStore
*/
public void initialize( int max )
{
this.max = max;
}
/**
* Puts an item to the LRUStore.
*
*@param ce Description of the Parameter
*/
public void update( ILRUElement ce )
{
addFirst( ce );
LRUElementDescriptor old = ( LRUElementDescriptor ) map.put(
ce.getKey(), first );
if ( first.equals( old ) )
{
// the same as an existing item.
removeNode( old );
}
// save a microsecond on the second call.
int size = map.size();
// need to spool at a certain percentage synchronously
if ( size max )
{
return;
}
else
{
// SPOOL LAST -- need to make this a grouping in a queue
if ( debugcmd )
{
p( IN RAM overflow );
}
// write the last item to disk.
try
{
// PUSH 5 TO DISK TO MINIMIZE THE TYPICAL
int chunkSizeCorrected = Math.min( size, chunkSize );
if ( debugcmd )
{
p( update: About to dump , map.size() = + size
+ , max = + max + , chunkSizeCorrected = + chunkSizeCorrected );
}
// The spool will put them in a disk event queue, so
there is no
// need to pre-queue the queuing. This would be a bit
wasteful
// and wouldn't save much time in this synchronous
call.
[collections][PATCH] Doc error in Bag
Documentation error in org/apache/commons/collections/Bag.java
If the bag contains less than i occurences, the item itwm will be
removed from the unique set implies that if the bag contains 5
occurences and i is 5, (5 is not less than 5) then the item will not be
removed from the unique set, even though there should be no more
occurances in the bag.
regards,
Michael
Index:
D:/home/michael/dev/jakarta/jakarta-commons/collections/src/java/org/apa
che/commons/collections/Bag.java
===
RCS file:
/home/cvspublic/jakarta-commons/collections/src/java/org/apache/commons/
collections/Bag.java,v
retrieving revision 1.1
diff -u -r1.1 Bag.java
---
D:/home/michael/dev/jakarta/jakarta-commons/collections/src/java/org/apa
che/commons/collections/Bag.java29 Aug 2001 15:28:07 - 1.1
+++
D:/home/michael/dev/jakarta/jakarta-commons/collections/src/java/org/apa
che/commons/collections/Bag.java1 Feb 2002 05:49:39 -
@@ -113,7 +113,7 @@
/**
* Remove the given number of occurrences from the bag. If the bag
-* contains less than codei/code occurrences, the item will be
+* contains codei/code occurrences or less, the item will be
* removed from the {@link #uniqueSet}.
* @see #getCount
* @see #remove(Object)
Bag.patch
Description: Binary data
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[collections][PATCH] Ambiguous documentation in FilterIterator
Ambiguous documentation in
org/apache/commons/collections/FilterIterator.java
The FilterIterator does not specify whether it *returns* objects that
match the predicate, or whether it ignores (i.e. does not return)
objects that match the predicate. This patch clarifies the API
documentation.
Regards,
Michael
Index:
D:/home/michael/dev/jakarta/jakarta-commons/collections/src/java/org/apa
che/commons/collections/FilterIterator.java
===
RCS file:
/home/cvspublic/jakarta-commons/collections/src/java/org/apache/commons/
collections/FilterIterator.java,v
retrieving revision 1.2
diff -u -r1.2 FilterIterator.java
---
D:/home/michael/dev/jakarta/jakarta-commons/collections/src/java/org/apa
che/commons/collections/FilterIterator.java 19 Oct 2001 20:18:21 -
1.2
+++
D:/home/michael/dev/jakarta/jakarta-commons/collections/src/java/org/apa
che/commons/collections/FilterIterator.java 1 Feb 2002 05:49:32 -
@@ -11,7 +11,8 @@
import java.util.NoSuchElementException;
/** A Proxy {@link Iterator Iterator} which takes a {@link Predicate
Predicate} instance to filter
- * out objects from an underlying {@link Iterator Iterator} instance.
+ * out objects from an underlying {@link Iterator Iterator} instance.
Only objects for which the
+ * specified codePredicate/code evaluates to codetrue/code are
returned.
*
* @author a href=mailto:[EMAIL PROTECTED];James Strachan/a
* @author Jan Sorensen
FilterIterator.patch
Description: Binary data
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[collections][PATCH] Various problems with AbstractBag
The following patch fixes the following problems with
org.apache.commons.collections.AbstractBag:
- Documentation does not specify exactly what a subcless needs to do to
extend AbstractBag to make a concrete subclass.
- AbstractBag.add(Object,int) has two calls to getCount(o), when only
one is necessary. This wastes a few cycles to perform method
invocations, a map lookup, a cast, and a few comparisons.
- The equals(Object) method will incorrectly throw a
NullPointerException if a null value is passed. The
Object.equals(Object) API specifies For any non-null reference value x,
x.equals(null) should return false.
- The equals(Object) method will only work if the object passed in
extends AbstractMap or implements Map. Neither of these facts is
documented, and neither is correct. The contract for
Object.equals(Object) states: for any reference values x and y,
x.equals(y) should return true if and only if y.equals(x) returns true.
. Returning true when the argument is a Map is incorrect since he
reverse (the map checking to see if its equal to the bag) will most
certainly be false. The same can be said for AbstractMap. A subclass
of AbstractMap may add extra data to be stored within the Bag that must
also be compared for them to be equal. The reverse comparison
(specialized subclass equals basic abstract bap) will fail. You can
read more about this in a three-year old, but still valid java world
article: http://www.javaworld.com/javaworld/jw-01-1999/jw-01-object.html
- if remove(Object,int) is called passing in 0 as the number to remove
and specifying an object that exists in th bag, true will be returned
from the method. Per the Bag API specification, true should only return
when an object is actually removed. Since no objects are removed, false
should be returned instead. Additionally, if a negative number is
specified, not only is the object not removed, but object(s) are *added*
(well, in the sense that it is equivalent of calling add(o, -i))
- the uniqueSet() method returns the set of unique objects, however the
set is modifiable. If the underlying map implementation has the set
backed by the map (as per the map contract -- so it should), then
elements can be removed form the unique set and have them removed from
the underlying map as well. This causes consistency problems with the
Bag since _total will then be incorrect.
- in extractList(), getCount(current) is called each time through the
inner loop, adding lots of extra overhead. Reversing the loop (starting
at the count and going down to 0) eliminates the excess overhead.
Note: In line with Elements of Java Style rule number 1, I have
adhered to the style of the original, using 3 space indents instead of 2
(which I believe is the agreed upon indent spacing). I've also left all
those ^M's in the file, even though they are completely annoying (I even
made sure my new lines of code had them to match the style of the rest).
Note: I felt catching and fixing all of the above was enough to warrant
adding my name to the author's list. If a committer disagrees, feel
free to remove it.
Regards,
Michael
Index:
D:/home/michael/dev/jakarta/jakarta-commons/collections/src/java/org/apa
che/commons/collections/AbstractBag.java
===
RCS file:
/home/cvspublic/jakarta-commons/collections/src/java/org/apache/commons/
collections/AbstractBag.java,v
retrieving revision 1.1
diff -u -r1.1 AbstractBag.java
---
D:/home/michael/dev/jakarta/jakarta-commons/collections/src/java/org/apa
che/commons/collections/AbstractBag.java29 Aug 2001 15:28:07 - 1.1
+++
D:/home/michael/dev/jakarta/jakarta-commons/collections/src/java/org/apa
che/commons/collections/AbstractBag.java1 Feb 2002 05:50:03 -
@@ -63,6 +63,7 @@
import java.util.ArrayList;
import java.util.Collection;
+import java.util.Collections;
import java.util.ConcurrentModificationException;
import java.util.Iterator;
import java.util.List;
@@ -73,8 +74,12 @@
/**
* This class provides a skeletal implementation of the {@link Bag}
* interface to minimize the effort required for target
implementations.
+ * Subclasses need only to call {@link #setMap(Map)} in their
constructor
+ * specifying a map instance that will be used to store the contents of
+ * the bag.
*
* @author Chuck Burdick
+ * @author a href=[EMAIL PROTECTED]Michael Smith/a
**/
public abstract class AbstractBag implements Bag {
private Map _map = null;
@@ -91,7 +96,7 @@
int count = (i + getCount(o));
_map.put(o, new Integer(count));
_total += i;
- return (getCount(o) == i);
+ return (count == i);
} else {
return false;
}
@@ -139,13 +144,9 @@
}
public boolean equals(Object o) {
- boolean result = false;
- if (o instanceof AbstractBag) {
- result = _map.equals(((AbstractBag)o).getMap());
- } else if (o instanceof Map) {
-
[collections][PATCH] SequencedHashMap violates Map contract, has poor performance
I've submitted this patch twice now (once back in mid-November, once a
week ago), but it still has yet to be committed. The patch is
essentially a complete rewrite of the SequencedHashMap class and fixes
the following problems:
- Adding and removing from the map is O(n) because the linked list
needs to be traversed to find the object to remove (when adding, the
object needs to be removed so it can be readded at the front as the most
recently used). There's been recent discussion on the commons list
about a LRU/MRU thing that is implemented using a linked list/hashtable
combination that had similar performance problems. This class
demonstrates a manner in which the O(n) performance of using the
LinkedList can be avoided by implementing a custom linked list in the
map entries themselves.
- The sets and collections returned by keySet(), values(), and
entries() are not properly backed by the map (in violation of the
java.util.Map contract).
The patch also adds an additional test case to verify that the remove()
method of the Iterator returned from keySet().iterator() is properly
backed by the map.
Regards,
Michael
p.s. Since the changes to SequencedHashMap were significant, I'm also
attaching a full version of the file for ease of glancing over the new
code.
Index:
D:/home/michael/dev/jakarta/jakarta-commons/collections/src/java/org/apa
che/commons/collections/SequencedHashMap.java
===
RCS file:
/home/cvspublic/jakarta-commons/collections/src/java/org/apache/commons/
collections/SequencedHashMap.java,v
retrieving revision 1.1
diff -u -r1.1 SequencedHashMap.java
---
D:/home/michael/dev/jakarta/jakarta-commons/collections/src/java/org/apa
che/commons/collections/SequencedHashMap.java 17 Sep 2001 16:43:49 -
1.1
+++
D:/home/michael/dev/jakarta/jakarta-commons/collections/src/java/org/apa
che/commons/collections/SequencedHashMap.java 1 Feb 2002 06:00:35 -
@@ -54,258 +54,507 @@
* http://www.apache.org/.
*/
+import java.util.Collections;
import java.util.Collection;
import java.util.HashMap;
import java.util.Iterator;
-import java.util.LinkedList;
+import java.util.AbstractCollection;
+import java.util.AbstractMap;
+import java.util.AbstractSet;
+import java.util.ArrayList;
import java.util.List;
import java.util.Map;
import java.util.Set;
+import java.util.NoSuchElementException;
/**
- * pA {@link java.util.HashMap} whose keys are sequenced. The
- * sequencing of the keys allow easy access to the values in the order
- * which they were added in. This class is thread safe./p
+ * A map of objects whose mapping entries are sequenced based on the
order in
+ * which they were added. This data structure has fast IO(1)/I
search
+ * time, deletion time, and insertion time.
*
- * pImplementing the List interface is not possible due to a instance
- * method name clash between the Collection and the List interface:
+ * This class inherits from {@link java.util.HashMap} purely for
backwards
+ * compatibility. It should really be inheriting from {@link
+ * java.util.AbstractMap}, or with a tiny extra bit of work, implement
the
+ * full map interface on its own. APIs should not rely on this class
being an
+ * actual {@link java.util.HashMap}, and instead should recognize it
only as a
+ * generic {@link java.util.Map} (unless, of course, you need the
sequencing
+ * functionality, but even in that case, this class should not be
referred to
+ * as a HashMap).
*
- * table
- * trtdCollections/tdtdboolean remove(Object o)/td/tr
- * trtdLists/tdtdObject remove(Object o)/td/tr
- * /table
- * /p
+ * PAlthough this map is sequenced, it cannot implement {@link
+ * java.util.List} because of incompatible interface definitions. The
remove
+ * methods in List and Map have different return values (see: {@link
+ * java.util.List#remove(Object)} and {@link
java.util.Map#remove(Object)}).
*
- * pSo one cannot implement both interfaces at the same, which is
- * unfortunate because the List interface would be very nice in
- * conjuction with a
- * href=http://jakarta.apache.org/velocity/;Velocity/a./p
- *
- * pA slightly more complex implementation and interface could
involve
- * the use of a list of codeMap.Entry/code objects./p
+ * PThis class is not thread safe. When a thread safe
implementation is
+ * required, wrap this class using {@link
Collections#synchronizedMap(Map)},
+ * or use explicit synchronization controls.
*
+ * @author a href=mailto:[EMAIL PROTECTED];Michael A.
Smith/A
* @author a href=mailto:[EMAIL PROTECTED];Daniel Rall/a
* @author a href=mailto:[EMAIL PROTECTED];Henning P.
Schmiedehausen/a
*/
-public class SequencedHashMap extends HashMap
-{
-/**
- * The index of the eldest element in the collection.
- */
-protected static final int ELDEST_INDEX = 0;
-
-/**
- * Indicator for an unknown index.
- */
-private static final int UNKNOWN_INDEX = -1;
-
-/**
-
