Re: [collections] pairs package name

[Rodney Waldhoff]

Maybe I just need to dig into this more deeply, but I find any form of
Pair or Object[2] class being exposed as a public interface of
commons-collections a bit questionable.

On Wed, 3 Dec 2003, __matthewHawthorne wrote:

> o.a.c.c.data could work.
>
> some other ideas:
> o.a.c.c.types
> o.a.c.c.elements
>
> Stephen Colebourne wrote:
> > KeyValue is not directly associated with maps - its a free form key value
> > pair. MultiKey could also be used in a List or Set.
> >
> > Stephen
> >
> > - Original Message -
> > From: "Rodney Waldhoff" <[EMAIL PROTECTED]>
> >
> >>Why can't these all just go with the maps?
> >>
> >>On Wed, 3 Dec 2003, Stephen Colebourne wrote:
> >>
> >>
> >>>The pairs package name is perhaps not quite right. I would like the
> >
> > package
> >
> >>>to hold all non-collection data structure:
> >>> - MapEntry
> >>> - KeyValue
> >>> - MultiKey
> >>>
> >>>How about renaming the package to data?
> >>>(no backwards compatability issues)
> >>>
> >>>Stephen
> >>>
> >>>
> >>>-
> >>>To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>>For additional commands, e-mail: [EMAIL PROTECTED]
> >>>
> >>>
> >>
> >>--
> >>- Rod 
> >>
> >>-
> >>To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>For additional commands, e-mail: [EMAIL PROTECTED]
> >>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-- 
- Rod 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 25186] New: - Security problem, BasicDataSource class

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25186

Security problem, BasicDataSource class

   Summary: Security problem, BasicDataSource class
   Product: Commons
   Version: 1.1 Final
  Platform: All
OS/Version: All
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Dbcp
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


In class org.apache.commons.dbcp.BasicDataSource there is a PUBLIC 
method "getPassword()". This is a critical security problem: If DBCP is used in 
Tomcat, a Tomcat admin will setup JNDI-Datasources. The deployer of a webapp 
should not know anything about the Datasource details especially not the 
password! Some developer could easy call "getPassword()" to hack the database. 
As a first solution "getPassword()" could be rewritten to always return "null" 
(later it could be removed), second the instance field "password" should change 
from "protected" to "private".

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [digester] variable expansion

[robert burrell donkin]

hi simon

On 4 Dec 2003, at 09:17, Simon Kitching wrote:



In VariableSubstitutor, you use lazy creation for variableAttributes.
I'm not sure there is much point to that. Given that the user has set 
up
var expansion in the first place, the object will almost certainly be
created sometime. However the existing code has to evaluate an
if-statement on each call to determine if the object already exists. I
think it also makes the code more complex than it needs to be. Why not
create it in the constructor as soon as it is known if there is an
attributeExpander or not?
you're probably right. they'd be a small saving if a null expander was 
passed in but we're probably better trading that for code clarity.

I think a comment is needed in the Substitutor "interface" specifying
that Digester guarantees never to hold the return value of the
substitute(Attributes) method past the next call to the method. It is
this behaviour that allows a single VariableAttributes object to be
reused by the VariableSubstitutor. This behaviour was obvious before,
when VariableAttributes was directly invoked from the Digester's
startElement method, but probably needs to be explicitly documented 
now.
yep. it's standard SAX behaviour but you're right about adding some 
javadocs for this.

i should probably go through and add some extra javadocs explanations 
to the Rule methods
saying that the Attributes may be recycled and should not be changed 
(but that'll have to wait till tomorrow).

You mention that you were considering whether it is necessary to have
Remy's VarExpander implementation as well as the MultiVariableExpander.
While it would be a shame to discard Remy's work, I don't see much
benefit from having an additional implementation.
'm going to look into this. tomcat's an important user for digester and 
even if the differences are very minor (or of arguable value), i'd 
probably be inclined to include both. i do think that probably your 
implementation provides everything that remy's does but i want to take 
some time to analyze it properly.

- robert

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [digester] variable expansion

[robert burrell donkin]

hi ash
On 3 Dec 2003, at 09:59, ASHWIN Suresh wrote:
Sorry to jump in to this thread this way, and perhaps it is too late 
now.
But, have the people here considered using the term "resolve"
for this concept?

Perhaps the interface could be named Resolver, with the method 
resolve().

I can think of ${foo} > xyz as resolving the definition rather than 
simple
substitution,
thow at a lower level of abstraction, it is substitution.

If this has been considered and vetoed, please ignore my email.
i'm usually pretty bad on naming at the best of times - and worse when 
i'm tied (too many lists, too little sleep 8-)

but i think that substitution is what the top level interface does 
(rather than resolution).

resolver is also an overused word in xml. we'd probably need to prefix 
it with an adjective -  VariableResolver, say. i think that 
VariableResolver is probably a slightly better name than 
VariableExpander for the interface decoupling the variable 
expansion/resolution implementation  but i think that simon's original 
name is very reasonable. i'd be happy to go with the consensus on this. 
comments anyone?

One more point:

The spelling "substituter" feels more natural to me than
"substitutor".
cf.:
to write --> writer
to drive --> driver
to expand --> expander


For Latinate words, the pattern is usually -or.
Constructor, translator, delegator, etc.
Whenever, the agent form is formed out of removal of -ion, the 
preferred
suffix is -or.
Thus, the more appropriate form is substitutor.
Again, perhaps this was already discussed.
you seem to have put a lot more thought into it than i did :)

i intended it as a bit of a play on words - substitutor ~ terminator. 
digester has an 'e' but 'o' is probably better grammar. again, i be 
happy to bow to consensus. views anyone?

- robert

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-er or -or: offshoot from [digester] variable expansion

[Ash]

> >
> > We haven't really talked about the terminology for this feature.
> > I think it is open for discussion. Good names help in so many ways.
>
> >
> > Yep, all your examples are right to have "-or".
> > And also function-->functor.
> >
> > I'm convinced. Substitutor it is (unless the decision is made
> > to rename
> > it completely :-)
>
> > English is strange, isn't it? Substitutor but Expander and Resolver.
> > How consistent (not)!
> >


I was thinking this topic of agent terms (-er -or) was not too relevant to
this list, or to any list full of techies.

But on second thought, I realize that it would be useful to have an idea of
the naming patterns, since we are all coining so many terms every other day.
Further, I have often winced at misnaming found in the technical terminology
(implementors and adaptors and the like.) I am thus tempted to include here
an old article in which I explained then whens and whys of -er and -or.

It also has an answer for Simon's musing (on consistency.)

Ash



Here goes..


-er v/s -or.
-

Which comes when? What is the pattern?

I attempt to answer the questions.

-er is the native (Old) English and common Germanic (Dutch,
German, etc) suffix for agent (the doer, the nomen agentis).
-or is the originally the Latin suffix for the same function.

-or is mostly found in latinate words, i.e., words derived from
Latin, either as emprunt or constructed in English using Latin
elements (roots, prefixes and suffixes.)

actor, doctor, investigator, professor, etc.

-er is the general suffix for unlatinate words (anything not part
of the above definition.)
Sometimes, you also find -ar, -eur, and -eer.

killer, seller, buyer, Englander, trainer, entertainer,
experiencer, etc.

There are however some historical "aberrations" to this pattern.

wrongly -or: advisor, ... I can't recall the examples now.
wrongly -er: motor, but promoter (motion, promotion)



The rule for making an -or agent-noun is this:

Get the -ion form. Remove -ion and add -or.

seduce: seduction -> seductor
destroy: destruction -> destructor (used in programming
terminology)
translate: translation -> translator

When there is no acceptable -ion form, use the -er formation.
Sometimes, the -er form is preferred, usually when the -ion form
is longer, or less attractive (English likes to shorten the words it will
use,
you see.)

adapt: adaptation -> adapter (there is also the exceptional
'adaptor', which is incongruous with the pattern)
implement: implementation -> implementer (-or here is incorrect)
revolve: revolution -> revolver   (rather than revolutor)
produce: production -> producer   (rather than productor)
consume: consumption -> consumer  (rather than consumptor, cf. Latin emptor)

Ashwin S





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons/digester/src/java/org/apache/commons/digester Substitutor.java

[rdonkin]

rdonkin 2003/12/03 15:36:13

  Modified:digester/src/java/org/apache/commons/digester
Substitutor.java
  Log:
  Improved javadocs
  
  Revision  ChangesPath
  1.2   +17 -6 
jakarta-commons/digester/src/java/org/apache/commons/digester/Substitutor.java
  
  Index: Substitutor.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/digester/src/java/org/apache/commons/digester/Substitutor.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- Substitutor.java  2 Dec 2003 23:21:16 -   1.1
  +++ Substitutor.java  3 Dec 2003 23:36:13 -   1.2
  @@ -83,8 +83,19 @@
   public abstract class Substitutor {
   
   /**
  - * Substitutes the attributes (before they are passed to the 
  - * Rule implementations's)
  + * Substitutes the attributes (before they are passed to the 
  + * Rule implementations's).
  + *
  + * Digester will only call this method a second time 
  + * once the original Attributes instance can be safely reused. 
  + * The implementation is therefore free to reuse the same 
Attributes instance
  + * for all calls.
  + *
  + * @param attributes the Attributes passed into 
Digester by the SAX parser, 
  + * not null (but may be empty)
  + * @return Attributes to be passed to the Rule 
implementations. 
  + * This method may pass back the Attributes passed in.
  + * Not null but possibly empty.
*/
   public abstract Attributes substitute(Attributes attributes);
   
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons/digester/src/java/org/apache/commons/digester/substitution VariableSubstitutor.java

[rdonkin]

rdonkin 2003/12/03 15:21:52

  Modified:digester/src/java/org/apache/commons/digester/substitution
VariableSubstitutor.java
  Log:
  Changed from lazy construction to construction when the substitutor is created. 
Suggested by Simon Kitching.
  
  Revision  ChangesPath
  1.2   +5 -7  
jakarta-commons/digester/src/java/org/apache/commons/digester/substitution/VariableSubstitutor.java
  
  Index: VariableSubstitutor.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/digester/src/java/org/apache/commons/digester/substitution/VariableSubstitutor.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- VariableSubstitutor.java  2 Dec 2003 23:21:39 -   1.1
  +++ VariableSubstitutor.java  3 Dec 2003 23:21:52 -   1.2
  @@ -116,6 +116,7 @@
   public VariableSubstitutor(VariableExpander attributesExpander, 
VariableExpander bodyTextExpander) {
   this.attributesExpander = attributesExpander;
   this.bodyTextExpander = bodyTextExpander;
  +variableAttributes = new VariableAttributes();
   }
   
   /**
  @@ -125,9 +126,6 @@
   public Attributes substitute(Attributes attributes) {
   Attributes results = attributes;
   if (attributesExpander != null) {
  -if (variableAttributes == null) {
  -variableAttributes = new VariableAttributes();
  -}
   variableAttributes.init(attributes, attributesExpander);
   results = variableAttributes;
   }
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [digester] variable expansion

[Ash ..]

-Original Message-
From: Simon Kitching [mailto:[EMAIL PROTECTED]
On Wed, 2003-12-03 at 22:59, ASHWIN Suresh wrote:
> Sorry to jump in to this thread this way, and perhaps it is too late 
now.
> But, have the people here considered using the term "resolve"
> for this concept?

I don't think it is too late for suggestions like this. Any time before
the release is not too late :-)
Glad abt that!


> Perhaps the interface could be named Resolver, with the method 
resolve().
> > I can think of ${foo} > xyz as resolving the definition rather than 
simple
> substitution,
> thow at a lower level of abstraction, it is substitution.

The concept of "substitution" is general; expanding/resolving variables
is just one application of the "substitution" feature. Possibly
"substitution" could be called "interception", "filtering",
"pre-processing", "manipulation".
I would go with you. Substitution is more generic, while resolving and 
expanding are more specific activities. Then can it be said that the package 
ought to be substitution, which contains classes (or perhaps methods within 
a class) that do more specific things like resolving and expanding??

Trying to make things more concrete:

Substitution: f(x) > y

Resolution: f(x) > y where,
x is explicitly a resolvabe, indicated by special symbols (escapes): such as 
${} and &;.

Expansion: f(x) > y where,
y is "longer" than x, conversely, x can be viewed as a 
shorter/contracted/abreviated form of y.

Replacement: f(x) > y
A simple replacement of x by y. (Thow the term substitution itself can carry 
this meaning, we "decide" to use that one with a higher/more generic value.)

Pre-processing:
When any kind of manipulation takes place BEFORE any kind of processing! 
Sounds simple eh.

Filtering: f(x) > y
Where sometimes x = y, and at other times, x gives a y that is distinct.


The "VarExpander" is implemented using the generic "substitution" 
mechanism.
I could go for "VarResolver" if other people like the term. The word 
"Resolver"
on its own, however, implies the SAX EntityResolver to me; at least that's 
what I would think of first..
There you are. Entities are another set of  "resolvables", that get 
resolved. So, let's say, we are on track, but here, we are doing variable 
resolving.


Note that the string to which "var expansion" (in the current terminology) 
is being applied can have multiple variables mixed with literal data. For 
example:
  "this is a ${var} and so is ${this}"
Is the process of converting this string to its final form "resolving"?
I'm going to sit firmly on the fence on this one :-)
Just getting the equivalent of ${var} is variable resolving. Do you propose 
another term for the whole process?

> > If this has been considered and vetoed, please ignore my email.

We haven't really talked about the terminology for this feature.
I think it is open for discussion. Good names help in so many ways.
Name game, am game!
Besides, what did draw my attention too was that I had only recently 
implemented some code to "resolve" an ant-like variable to its final value.


> > One more point:
> > > The spelling "substituter" feels more natural to me than > > 
"substitutor".
> > > > cf.:
> > to write --> writer
> > to drive --> driver
> > to expand --> expander
> > > For Latinate words, the pattern is usually -or.
> Constructor, translator, delegator, etc.
> Whenever, the agent form is formed out of removal of -ion, the preferred
> suffix is -or.
> Thus, the more appropriate form is substitutor.
> Again, perhaps this was already discussed.

Yep, all your examples are right to have "-or".
And also function-->functor.
I'm convinced. Substitutor it is (unless the decision is made to rename
it completely :-)
Funnily, digester then must be renamed to digestor!
("Now, who's that feisty suggestor?", would you say? ;-))

English is strange, isn't it? Substitutor but Expander and Resolver.
How consistent (not)!
Strange it is. But there are reasons underlying it. Etymology being one of 
my passions, I have unearthed some of the reasons, but more on that, another 
day, and perhaps on another list.

Ash

_
Get Hotmail on your mobile phone http://www.msn.co.uk/msnmobile
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [collections] Race condition

[Michael Heuer]

I gave it multiple tries but haven't been able to reproduce this
failure either, under maven and OSX JDK 1.4.1_01 or Sun Linux JDK 1.4.2.

   michael


On Wed, 3 Dec 2003, Stephen Colebourne wrote:

> I've seen it once today. Maybe its just my setup - as far as I can see there
> is no threading in these tests...
> Stephen
> Sun JDK1.4.1 Windows98
>
> - Original Message -
> From: "Phil Steitz" <[EMAIL PROTECTED]>
> > I am not seeing these failures.  Did recent commits include a fix?  If so,
> > where?  I am running the tests under maven, Sun Linux JDK 1.4.2.
> >
> > Phil
> >
> > Stephen Colebourne wrote:
> > > HELP!
> > > Anyone got any good ideas or tools to track this down. It is now very
> > > occaisional, but may knock out the next gump run! Today it only happens
> when
> > > I run TestAllPackages.
> > > Stephen
> > >
> > > - Original Message -
> > > From: "Stephen Colebourne" <[EMAIL PROTECTED]>
> > > To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>
> > > Sent: Tuesday, December 02, 2003 12:46 AM
> > > Subject: [collections] Race condition
> > >
> > >
> > >
> > >>Sadly there seems to be a race condition in one of the new classes/tests
> > >>
> > >>There was 1 failure:
> > >>1)
> testMapIteratorSet(TestFlat3Map.bulkTestMapIterator.testMapIteratorSet)
> > >>junit.framework.AssertionFailedError: Map must not contain old value
> > >>expected: but was:
> > >> at
> > >>
> > >
> > >
> org.apache.commons.collections.iterators.AbstractTestMapIterator.testMapIter
> > >
> > >>atorSet(AbstractTestMapIterator.java:267)
> > >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > >> at
> > >>
> > >
> > >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
> > >
> > >>)
> > >> at
> > >>
> > >
> > >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
> > >
> > >>.java:25)
> > >> at org.apache.commons.collections.map.TestAll.main(TestAll.java:80)
> > >>
> > >>When I run with Eclipse debugger the error is in TestFlat3Map. When I
> run
> > >>without the debugger, the error is in TestHashedMap. And occaisionaly it
> > >>works.
> > >>
> > >>I'm going to sleep, so I'll disable the test for the moment in case Gump
> > >>runs. If anyone wants to play they're welcome - I'm guessing its the
> test
> > >>thats bad.
> > >>
> > >>Stephen
> > >>
> > >>
> > >>
> > >>-
> > >>To unsubscribe, e-mail: [EMAIL PROTECTED]
> > >>For additional commands, e-mail: [EMAIL PROTECTED]
> > >>
> > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [digester] variable expansion

[Simon Kitching]

On Fri, 2003-12-05 at 11:17, Simon Kitching wrote:
> Hi Robert,
> 
> I think the code committed is just fine.

On further thought, I have a more significant change to suggest.

I think the VariableSubstitutor and MultiVariableExpander classes should
be merged. VariableSubstitutor really is a nothing class, just
delegating all its work to other classes. 

If it is decided to have just one implementation that handles both the
simple ant-like case, and the more complex implementation currently in
MultiVariableExpander, then the resulting class name could be
"BaseVariableSubstitutor", otherwise it could be called
MultiVariableSubstitutor.

I suggest that the (new) BaseVariableSubstitutor should implement both
Substitutor and VariableExpander, and pass itself to the
VariableAttributes class as the expander to use.

This does mean that the constructor would need to change:
  public BaseVariableSubstitutor(boolean doAttributes, boolean doBody)


PRO:
* one less class in the digester code base
* one less class for the user to deal with.
  they just instantiate a BaseVariableSubstitutor (or whatever) rather
  than both a VariableSubstitutor and a MultiVariableExpander.

CON:
A user can't just write a new VariableExpander implementation; they
need to write a new Substitutor implementation instead. However as
noted above, the code currently in VariableSubstitutor is pretty
trivial; I can't see that being an issue in practice.


Regards,

Simon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [digester] variable expansion

[Simon Kitching]

On Wed, 2003-12-03 at 22:59, ASHWIN Suresh wrote:
> Sorry to jump in to this thread this way, and perhaps it is too late now.
> But, have the people here considered using the term "resolve"
> for this concept?

I don't think it is too late for suggestions like this. Any time before
the release is not too late :-)

> Perhaps the interface could be named Resolver, with the method resolve().
> 
> I can think of ${foo} > xyz as resolving the definition rather than simple
> substitution,
> thow at a lower level of abstraction, it is substitution.

The concept of "substitution" is general; expanding/resolving variables
is just one application of the "substitution" feature. Possibly
"substitution" could be called "interception", "filtering",
"pre-processing", "manipulation". 

The "VarExpander" is implemented using the generic "substitution" mechanism.
I could go for "VarResolver" if other people like the term. The word "Resolver"
on its own, however, implies the SAX EntityResolver to me; at least that's what 
I would think of first..


Note that the string to which "var expansion" (in the current terminology) 
is being applied can have multiple variables mixed with literal data. 
For example:
  "this is a ${var} and so is ${this}"
Is the process of converting this string to its final form "resolving"?
I'm going to sit firmly on the fence on this one :-)

> 
> If this has been considered and vetoed, please ignore my email.

We haven't really talked about the terminology for this feature.
I think it is open for discussion. Good names help in so many ways.

> 
> One more point:
> 
> > The spelling "substituter" feels more natural to me than 
> > "substitutor".
> > 
> > cf.:
> > to write --> writer
> > to drive --> driver
> > to expand --> expander
> 
> 
> For Latinate words, the pattern is usually -or.
> Constructor, translator, delegator, etc.
> Whenever, the agent form is formed out of removal of -ion, the preferred
> suffix is -or.
> Thus, the more appropriate form is substitutor.
> Again, perhaps this was already discussed.

Yep, all your examples are right to have "-or".
And also function-->functor.

I'm convinced. Substitutor it is (unless the decision is made to rename
it completely :-)

English is strange, isn't it? Substitutor but Expander and Resolver.
How consistent (not)!




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[collections] general roadmap

[Ash ..]

Hello,

I would like to have a general idea of the go-whither of the collections 
project. I mean, what are the general objectives of package for the 
immediate future, when is the next release slated, and such stuff. I did 
take a peek at the CVS for the docs that explain this, but most seem to be 
rather old (2-3 months and the like). I would appreciate pointers/more info 
on this.

Thanks,
Ash
_
On the move? Get Hotmail on your mobile phone http://www.msn.co.uk/msnmobile
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[configuration] binary builds.

[Hernan Silberman]

I know it's a Sandbox project, but I was wondering if there's anywhere I can 
find recent builds of configuration to play with.  I'm behind a firewall at work 
and have had little luck getting cvsGrab to work through the local HTTP proxy.  
Even if I do manage to get a copy of that module, the ant build process requires 
unfettered HTTP access to fetch all the required jars it needs.  I haven't been 
able to find snapshots or other built copies of this project, are they out there?

thanks!
Hernan


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons-sandbox/sql/src/java/org/apache/commons/sql/type TypesWriter.java

[matth]

matth   2003/12/03 13:03:00

  Modified:sql  project.xml
   sql/src/java/org/apache/commons/sql/io DatabaseWriter.java
   sql/src/java/org/apache/commons/sql/type TypesWriter.java
  Log:
  Replaced some dependencies - jelly-SNAPSHOT switched to latest version, xerces moved 
back to 2.4 from 2.5 since the latest isn't on ibiblio.  Removed some deprecated refs 
to method in betwixt.  Added self as project developer.
  
  Revision  ChangesPath
  1.14  +8 -6  jakarta-commons-sandbox/sql/project.xml
  
  Index: project.xml
  ===
  RCS file: /home/cvs/jakarta-commons-sandbox/sql/project.xml,v
  retrieving revision 1.13
  retrieving revision 1.14
  diff -u -r1.13 -r1.14
  --- project.xml   18 Nov 2003 23:19:13 -  1.13
  +++ project.xml   3 Dec 2003 21:03:00 -   1.14
  @@ -71,6 +71,12 @@
 SpiritSoft, Inc.
   
   
  +
  +  Matthew Hawthorne
  +  matth
  +  [EMAIL PROTECTED]
  +
  +
 
   
   
  @@ -98,10 +104,6 @@
   
   
 commons-collections
  -  
 3.0-dev
   
   
  @@ -117,7 +119,7 @@
   
   
 commons-jelly
  -  SNAPSHOT
  +  20030902.160215
   
   
   
  @@ -149,7 +151,7 @@
   
   
 xerces
  -  2.5.0
  +  2.4.0
   
   
   
  
  
  
  1.4   +2 -4  
jakarta-commons-sandbox/sql/src/java/org/apache/commons/sql/io/DatabaseWriter.java
  
  Index: DatabaseWriter.java
  ===
  RCS file: 
/home/cvs/jakarta-commons-sandbox/sql/src/java/org/apache/commons/sql/io/DatabaseWriter.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- DatabaseWriter.java   13 Oct 2003 08:30:13 -  1.3
  +++ DatabaseWriter.java   3 Dec 2003 21:03:00 -   1.4
  @@ -56,10 +56,7 @@
* individuals on behalf of the Apache Software Foundation.  For more
* information on the Apache Software Foundation, please see
* .
  - * 
  - * $Id$
*/
  -
   package org.apache.commons.sql.io;
   
   import java.io.OutputStream;
  @@ -71,6 +68,7 @@
* This class outputs a fully populated Database bean as XML.
* 
* @author mailto:[EMAIL PROTECTED]">James Strachan
  + * @author Matthew Hawthorne
* @version $Revision$
*/
   public class DatabaseWriter extends BeanWriter {
  @@ -91,6 +89,6 @@
   private void init() {
   setXMLIntrospector( DatabaseReader.newXMLIntrospector() );
   enablePrettyPrint();
  -setWriteIDs(false);
  +getBindingConfiguration().setMapIDs(false);
   }
   }
  
  
  
  1.3   +61 -1 
jakarta-commons-sandbox/sql/src/java/org/apache/commons/sql/type/TypesWriter.java
  
  Index: TypesWriter.java
  ===
  RCS file: 
/home/cvs/jakarta-commons-sandbox/sql/src/java/org/apache/commons/sql/type/TypesWriter.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- TypesWriter.java  30 Apr 2003 11:27:31 -  1.2
  +++ TypesWriter.java  3 Dec 2003 21:03:00 -   1.3
  @@ -1,3 +1,62 @@
  +/*
  + * $Header$
  + * $Revision$
  + * $Date$
  + *
  + * 
  + *
  + * 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 acknowledgement:
  + *   "This product includes software developed by the
  + *Apache Software Foundation (http://www.apache.org/)."
  + *Alternately, this acknowledgement may appear in the software itself,
  + *if and wherever such third-party acknowledgements 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 prior written permission. For written
  + *permission, please contact [EMAIL PROTECTED]
  + *
  + * 5. Products derived from this software may not be called "Apache"
  + *nor may "Apache" appear in their names without prior written
  + *permission of the Apache Sof

RE: [collections] pairs package name

[ASHWIN Suresh]

"data" would be fine but somehow I feel a name like that is too generic. 
I mean, it's all data! So, the name did rather describe what the classes do
with data.

So, one might call it: 
oacc.dataholders

Or, if that is long, how about just  oacc.holders

Or something that describes that these elements hold/have data.

Ash


> -Original Message-
> From: __matthewHawthorne [mailto:[EMAIL PROTECTED]
> 
> 
> o.a.c.c.data could work.
> 
> some other ideas:
> o.a.c.c.types
> o.a.c.c.elements

> 
> 
> Stephen Colebourne wrote:
> > KeyValue is not directly associated with maps - its a free 
> form key value
> > pair. MultiKey could also be used in a List or Set.
> > 
> > Stephen
> > 
> > - Original Message -
> > From: "Rodney Waldhoff" <[EMAIL PROTECTED]>
> > 
> >>Why can't these all just go with the maps?
> >>
> >>On Wed, 3 Dec 2003, Stephen Colebourne wrote:
> >>
> >>
> >>>The pairs package name is perhaps not quite right. I would like the
> > 
> > package
> > 
> >>>to hold all non-collection data structure:
> >>> - MapEntry
> >>> - KeyValue
> >>> - MultiKey
> >>>
> >>>How about renaming the package to data?
> >>>(no backwards compatability issues)
> >>>
> >>>Stephen
> >>>
> >>>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[codec] Web presence not 1.2

[Gary Gregory]

Hello,

The web presence is 1.2 RC1 and not 1.2:
http://jakarta.apache.org/commons/codec/

The web presence is 1.1 and not 1.2:
http://jakarta.apache.org/site/binindex.cgi

Thanks,
Gary

cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collections/map package.html

[scolebourne]

scolebourne2003/12/03 11:23:08

  Modified:collections/src/java/org/apache/commons/collections/map
package.html
  Log:
  Add LinkedMap map implementation
  
  Revision  ChangesPath
  1.5   +3 -0  
jakarta-commons/collections/src/java/org/apache/commons/collections/map/package.html
  
  Index: package.html
  ===
  RCS file: 
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/map/package.html,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- package.html  3 Dec 2003 15:50:12 -   1.4
  +++ package.html  3 Dec 2003 19:23:08 -   1.5
  @@ -2,12 +2,15 @@
   
   This package contains implementations of the Map, OrderedMap and SortedMap 
interfaces.
   A Map provides a lookup from a key to a value.
  +A number of implementations also support the new MapIterator interface that enables
  +simple iteration of map keys and values.
   
   The following implementations are provided:
   
   HashedMap - general purpose HashMap replacement supporting MapIterator
   IdentityMap - Map that uses == for comparison instead of equals()
   Flat3Map - designed for good performance at size 3 or less
  +LinkedMap - a hash map that maintains insertion order, supporting 
OrderedMapIterator
   ReferenceMap - allows the garbage collector to collect keys and values
   StaticBucketMap - internally synchronized and designed for thread-contentious 
environments
   
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [collections] pairs package name

[__matthewHawthorne]

o.a.c.c.data could work.

some other ideas:
o.a.c.c.types
o.a.c.c.elements


Stephen Colebourne wrote:
KeyValue is not directly associated with maps - its a free form key value
pair. MultiKey could also be used in a List or Set.
Stephen

- Original Message -
From: "Rodney Waldhoff" <[EMAIL PROTECTED]>
Why can't these all just go with the maps?

On Wed, 3 Dec 2003, Stephen Colebourne wrote:


The pairs package name is perhaps not quite right. I would like the
package

to hold all non-collection data structure:
- MapEntry
- KeyValue
- MultiKey
How about renaming the package to data?
(no backwards compatability issues)
Stephen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

--
- Rod 
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [collections] pairs package name

[Stephen Colebourne]

KeyValue is not directly associated with maps - its a free form key value
pair. MultiKey could also be used in a List or Set.

Stephen

- Original Message -
From: "Rodney Waldhoff" <[EMAIL PROTECTED]>
> Why can't these all just go with the maps?
>
> On Wed, 3 Dec 2003, Stephen Colebourne wrote:
>
> > The pairs package name is perhaps not quite right. I would like the
package
> > to hold all non-collection data structure:
> >  - MapEntry
> >  - KeyValue
> >  - MultiKey
> >
> > How about renaming the package to data?
> > (no backwards compatability issues)
> >
> > Stephen
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> --
> - Rod 
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons/collections/data/test LinkedMap.fullCollection.version3.obj LinkedMap.emptyCollection.version3.obj

[scolebourne]

scolebourne2003/12/03 11:05:51

  Added:   collections/data/test LinkedMap.fullCollection.version3.obj
LinkedMap.emptyCollection.version3.obj
  Log:
  Add LinkedMap map implementation
  
  Revision  ChangesPath
  1.1  
jakarta-commons/collections/data/test/LinkedMap.fullCollection.version3.obj
  
<>
  
  
  1.1  
jakarta-commons/collections/data/test/LinkedMap.emptyCollection.version3.obj
  
<>
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons/collections/src/test/org/apache/commons/collections/map TestLinkedMap.java TestAll.java

[scolebourne]

scolebourne2003/12/03 11:04:41

  Modified:collections/src/java/org/apache/commons/collections/map
HashedMap.java
   collections/src/test/org/apache/commons/collections/map
TestAll.java
  Added:   collections/src/java/org/apache/commons/collections/map
LinkedMap.java
   collections/src/test/org/apache/commons/collections/map
TestLinkedMap.java
  Log:
  Add LinkedMap map implementation
  
  Revision  ChangesPath
  1.5   +44 -15
jakarta-commons/collections/src/java/org/apache/commons/collections/map/HashedMap.java
  
  Index: HashedMap.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/map/HashedMap.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- HashedMap.java2 Dec 2003 23:51:50 -   1.4
  +++ HashedMap.java3 Dec 2003 19:04:41 -   1.5
  @@ -105,21 +105,21 @@
   protected static final Object NULL = new Object();
   
   /** Load factor, normally 0.75 */
  -private final float loadFactor;
  +protected final float loadFactor;
   /** The size of the map */
  -private transient int size;
  +protected transient int size;
   /** Map entries */
  -private transient HashEntry[] data;
  +protected transient HashEntry[] data;
   /** Size at which to rehash */
  -private transient int threshold;
  +protected transient int threshold;
   /** Modification count for iterators */
  -private transient int modCount;
  +protected transient int modCount;
   /** Entry set */
  -private transient EntrySet entrySet;
  +protected transient EntrySet entrySet;
   /** Key set */
  -private transient KeySet keySet;
  +protected transient KeySet keySet;
   /** Values */
  -private transient Values values;
  +protected transient Values values;
   
   /**
* Constructs a new empty map with default size and load factor.
  @@ -129,6 +129,7 @@
   this.loadFactor = DEFAULT_LOAD_FACTOR;
   this.threshold = calculateThreshold(DEFAULT_CAPACITY, DEFAULT_LOAD_FACTOR);
   this.data = new HashEntry[DEFAULT_CAPACITY];
  +init();
   }
   
   /**
  @@ -162,6 +163,7 @@
   this.threshold = calculateThreshold(initialCapacity, loadFactor);
   initialCapacity = calculateNewCapacity(initialCapacity);
   this.data = new HashEntry[initialCapacity];
  +init();
   }
   
   /**
  @@ -175,6 +177,12 @@
   putAll(map);
   }
   
  +/**
  + * Initialise subclasses during construction.
  + */
  +protected void init() {
  +}
  +
   //---
   /**
* Gets the value mapped to the key specified.
  @@ -353,6 +361,25 @@
   
   //---
   /**
  + * Gets the entry mapped to the key specified.
  + * 
  + * @param key  the key
  + * @return the entry, null if no match
  + */
  +protected HashEntry getEntry(Object key) {
  +key = convertKey(key);
  +int hashCode = hash(key);
  +HashEntry entry = data[hashIndex(hashCode, data.length)]; // no local for 
hash index
  +while (entry != null) {
  +if (entry.hashCode == hashCode && isEqualKey(key, entry.key)) {
  +return entry;
  +}
  +entry = entry.next;
  +}
  +return null;
  +}
  +
  +/**
* Converts input keys to another object for storage in the map.
* This implementation masks nulls.
* Subclasses can override this to perform alternate key conversions.
  @@ -875,11 +902,11 @@
* Base Iterator
*/
   protected static abstract class HashIterator implements Iterator {
  -private final HashedMap map;
  -private int hashIndex;
  -private HashEntry current;
  -private HashEntry next;
  -private int expectedModCount;
  +protected final HashedMap map;
  +protected int hashIndex;
  +protected HashEntry current;
  +protected HashEntry next;
  +protected int expectedModCount;
   
   protected HashIterator(HashedMap map) {
   super();
  @@ -966,6 +993,7 @@
   int capacity = in.readInt();
   int size = in.readInt();
   data = new HashEntry[capacity];
  +init();
   for (int i = 0; i < size; i++) {
   Object key = in.readObject();
   Object value = in.readObject();
  @@ -987,6 +1015,7 @@
   cloned.values = null;
   cloned.modCount = 0;
   cloned.size = 0;
  +init();
  

cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collections/map Flat3Map.java

[scolebourne]

scolebourne2003/12/03 11:03:50

  Modified:collections/src/java/org/apache/commons/collections/map
Flat3Map.java
  Log:
  Change to use HashedMap instead of HashMap
  
  Revision  ChangesPath
  1.6   +6 -8  
jakarta-commons/collections/src/java/org/apache/commons/collections/map/Flat3Map.java
  
  Index: Flat3Map.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/map/Flat3Map.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- Flat3Map.java 2 Dec 2003 23:51:50 -   1.5
  +++ Flat3Map.java 3 Dec 2003 19:03:50 -   1.6
  @@ -60,7 +60,6 @@
   import java.util.AbstractCollection;
   import java.util.AbstractSet;
   import java.util.Collection;
  -import java.util.HashMap;
   import java.util.Iterator;
   import java.util.Map;
   import java.util.NoSuchElementException;
  @@ -70,7 +69,6 @@
   import org.apache.commons.collections.IteratorUtils;
   import org.apache.commons.collections.MapIterator;
   import org.apache.commons.collections.ResettableIterator;
  -import org.apache.commons.collections.iterators.EntrySetMapIterator;
   
   /**
* A Map implementation that stores data in simple fields until
  @@ -127,7 +125,7 @@
   /** Value, used while in flat mode */
   private Object iValue3;
   /** Map, used while in delegate mode */
  -private HashMap iMap;
  +private HashedMap iMap;
   
   /**
* Constructor.
  @@ -388,7 +386,7 @@
* Converts the flat map data to a HashMap.
*/
   private void convertToMap() {
  -iMap = new HashMap();
  +iMap = new HashedMap();
   switch (iSize) {  // drop through
   case 3:
   iMap.put(iKey3, iValue3);
  @@ -578,13 +576,13 @@
* A MapIterator returns the keys in the map. It also provides convenient
* methods to get the key and value, and set the value.
* It avoids the need to create an entrySet/keySet/values object.
  - * It also avoids creating the Mep Entry object.
  + * It also avoids creating the Map Entry object.
* 
* @return the map iterator
*/
   public MapIterator mapIterator() {
   if (iMap != null) {
  -return new EntrySetMapIterator(this);
  +return iMap.mapIterator();
   }
   if (iSize == 0) {
   return IteratorUtils.EMPTY_MAP_ITERATOR;
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons/collections/src/test/org/apache/commons/collections/iterators AbstractTestOrderedMapIterator.java

[scolebourne]

scolebourne2003/12/03 11:03:21

  Modified:collections/src/test/org/apache/commons/collections/iterators
AbstractTestOrderedMapIterator.java
  Log:
  Improve testing of iterators
  
  Revision  ChangesPath
  1.4   +4 -2  
jakarta-commons/collections/src/test/org/apache/commons/collections/iterators/AbstractTestOrderedMapIterator.java
  
  Index: AbstractTestOrderedMapIterator.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/collections/src/test/org/apache/commons/collections/iterators/AbstractTestOrderedMapIterator.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- AbstractTestOrderedMapIterator.java   1 Dec 2003 22:48:58 -   1.3
  +++ AbstractTestOrderedMapIterator.java   3 Dec 2003 19:03:21 -   1.4
  @@ -196,11 +196,13 @@
   assertEquals(it2.next(), key);
   list.add(key);
   }
  +assertEquals(map.size(), list.size());
   while (it.hasPrevious()) {
   Object key = it.previous();
   assertEquals(list.get(list.size() - 1), key);
   list.remove(list.size() - 1);
   }
  +assertEquals(0, list.size());
   }
   
   }
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: to the developers of Jelly

[Paul Libbrecht]

Hi Ernesto!

I am not sure I do understand what it means to invoke a function of a 
tag-library at least in Jelly. From what I understood from the first 
answer to your question, it looks like straight invocation would do.

How about the following ?

  
  ${instance.doSomething()}
 
TagLibraries in Jelly are instantiated objects which are closer to 
"tag-factories"... so it's kind of not compatible to your usage. But 
there's large freedom in creating and manipulating object, always being 
possible to output some XML content through SAX events.

Paul



Reinaldo Barreiro, E. wrote:
I hope this is the correct list to send this e-mail. 

I have installed Jelly and perused a bit the source code and documentation. 
I'm planning to use it for one of our projects... Well the question I want to ask is: 

Is it possible to define your own functions on a Jelly tag library (the same 
way it is possible on JSP 2.0)? Like in:



${param.value}



In my view that is a very powerfull feature of JSP 2.0. and it would be 
nice to have it in Jelly. My apologies to the developers if the feature is 
already there and I didn't mangage to find how to use it.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [collections] pairs package name

[Rodney Waldhoff]

Why can't these all just go with the maps?

On Wed, 3 Dec 2003, Stephen Colebourne wrote:

> The pairs package name is perhaps not quite right. I would like the package
> to hold all non-collection data structure:
>  - MapEntry
>  - KeyValue
>  - MultiKey
>
> How about renaming the package to data?
> (no backwards compatability issues)
>
> Stephen
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-- 
- Rod 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Please, tell me about my patch

[stutz]

Hello, guys, I found bugs in beanutils as posted in

 http://issues.apache.org/bugzilla/show_bug.cgi?id=24941

I posted patches for the bugs too and wanted to know if it was fixed in the
right way or I need to alter it in any way.
These bugs are blocking another bug issue for Struts.

Hopefully,

Stutz


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons-sandbox/functor STATUS.txt

[rwaldhoff]

rwaldhoff2003/12/03 10:22:11

  Modified:functor/xdocs examples.xml download.xml building.xml
index.xml
   functor/xdocs/stylesheets project.xml
  Added:   functor  STATUS.txt
  Log:
  add STATUS.txt
  update xdocs
  
  Revision  ChangesPath
  1.6   +53 -2 jakarta-commons-sandbox/functor/xdocs/examples.xml
  
  Index: examples.xml
  ===
  RCS file: /home/cvs/jakarta-commons-sandbox/functor/xdocs/examples.xml,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- examples.xml  26 Nov 2003 01:28:36 -  1.5
  +++ examples.xml  3 Dec 2003 18:22:10 -   1.6
  @@ -46,16 +46,67 @@
 or
 maven -Dtestcase=org.apache.commons.functor.example.TestAll 
test:single
 
  - Each example is written in something like a literate programming style.
  - In other words, with descriptive prose mixed right in with the source, as 
  + Each example is has descriptive prose mixed right in with the source, as 
/* C++ style */ comments.
 
  +  
  +
  +  "Pragmatic" Dave Thomas has been 
  +  http://pragprog.com/pragdave/";>blogging 
  +  a series of programming exercises he calls 
  +  http://pragprog.com/pragdave/Practices/Kata";>Code Katas.
  +  These exercises are intended to provide "practice sesssions" that allow
  +  programmers to hone their craft.  The notion is borrowed from the 
  +  practice of Karate, where, in Dave's words 
  +  "a kata is an exercise where you repeat a form many, many times, 
  +  making little improvements in each".
  +
  +
  +  Here we use several of Dave's Code Katas to explore the
  +  Commons-Functor library.
  +
  +
  +  http://jakarta.apache.org/commons/sandbox/functor/xref-test/org/apache/commons/functor/example/kata/one/package-summary.html";>Kata
 One: Supermarket Pricing
  +  
  +Dave's http://pragprog.com/pragdave/Practices/Kata/KataOne.rdoc,v";>Kata One asks how
  +one might implement supermarket pricing rules, like "three for a 
dollar" or "buy two get one free".
  +By encapsulating tiny bits of logic, functors provide a useful solution 
to this problem, as 
  +illustrated in the 
  +http://jakarta.apache.org/commons/sandbox/functor/xref-test/org/apache/commons/functor/example/kata/one/SupermarketPricingExample.html";>SupermarketPricingExample.
  +  
  +
  +  http://jakarta.apache.org/commons/sandbox/functor/xref-test/org/apache/commons/functor/example/kata/two/package-summary.html";>Kata
 Two: Binary Chop
  +  
  +http://pragprog.com/pragdave/Practices/Kata/KataTwo.rdoc,v";>Kata Two asks us
  +to create several different implemenations of the binary search 
algorithm, which once you
  +get past three or four implemenations, is more difficult that it 
sounds.
  +http://jakarta.apache.org/commons/sandbox/functor/xref-test/org/apache/commons/functor/example/kata/two/TestBinaryChop.html";>TestBinaryChop
  +presents several implementations, with functor and non-functor 
variations.
  +  
  +
  +
  +  http://jakarta.apache.org/commons/sandbox/functor/xref-test/org/apache/commons/functor/example/kata/four/package-summary.html";>Kata
 Four: Data Munging
  +  
  +http://pragprog.com/pragdave/Practices/Kata/KataFour.doc,v";>Kata Four asks us
  +to explore extreme reuse.  Our
  +http://jakarta.apache.org/commons/sandbox/functor/xref-test/org/apache/commons/functor/example/kata/four/DataMunger.html";>DataMunger
  +allows for very small implementations of the 
  +http://jakarta.apache.org/commons/sandbox/functor/xref-test/org/apache/commons/functor/example/kata/four/TestWeather.html";>weather
  +and
  +http://jakarta.apache.org/commons/sandbox/functor/xref-test/org/apache/commons/functor/example/kata/four/TestSoccer.html";>soccer
 (football)
  +parsers.
  +  
  +
  +
  +
  +  
 
   
 The lines
 package demonstrates a functional approach to IO using Generators and the 
Algorithms class.
   
   
  +  
 

   The Functor package, and more generally, a functional approach
  
  
  
  1.4   +1 -1  jakarta-commons-sandbox/functor/xdocs/download.xml
  
  Index: download.xml
  ===
  RCS file: /home/cvs/jakarta-commons-sandbox/functor/xdocs/download.xml,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- download.xml 

DO NOT REPLY [Bug 25167] - NullPointerException in SocketClient.getRemoteAddress()

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25167

NullPointerException in SocketClient.getRemoteAddress()





--- Additional Comments From [EMAIL PROTECTED]  2003-12-03 17:53 ---
I forgot to add than an argument can be made to protect against the setting
of SocketClient._socket_ to a null value by a user-defined subclass, but that
can be addressed by documenting a requirement to set SocketClient._socket_
to null only in a constructor or in disconnect() and to assign it a non-null
value only in connect().  In general, Commons Net has been implemented to
avoid checks for illegal state conditions and delegate responsibility
to the programmer not to call connection-dependent methods while disconnected.
If we agree to use methods specific to J2SE 1.4, then changing
SocketClient.isConnected() to
{ return (_socket_ != null && _socket_.isConnected()); }
would go a long way to helping programmers.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 25167] - NullPointerException in SocketClient.getRemoteAddress()

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25167

NullPointerException in SocketClient.getRemoteAddress()

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-12-03 17:40 ---
Although the suggestion appears at first to make good sense, the problem is that
SocketClient._socket_ is assigned a value by a call to connect() and afterward
only acquires a null value by a call to disconnect().  If a call to
disconnect() is not made, but the TCP connection is severed, a valid Socket
instance will remain and Socket.getInetAddress() will return null.  The
condition described by this issue report can only have arisen by an explicit
call to disconnect() and would indicate a programming error.  I am therefore 
going to mark this report invalid, but leave it open to allow the reporter 
additional time to examine his code and investigate the problem.  If there is
indeed some way to set SocketClient._socket_ to null without calling
disconnect(), then it is something we need to fix.  However, if you search
the Commons Net code for all assignments to SocketClient._socket_
(grep "_socket_ *=" $(find src/java -name *".java" -print)), you
will find the only null assignments occur in the SocketClient constructor
and in disconnect().

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [collections] Race condition

[Stephen Colebourne]

I've seen it once today. Maybe its just my setup - as far as I can see there
is no threading in these tests...
Stephen
Sun JDK1.4.1 Windows98

- Original Message -
From: "Phil Steitz" <[EMAIL PROTECTED]>
> I am not seeing these failures.  Did recent commits include a fix?  If so,
> where?  I am running the tests under maven, Sun Linux JDK 1.4.2.
>
> Phil
>
> Stephen Colebourne wrote:
> > HELP!
> > Anyone got any good ideas or tools to track this down. It is now very
> > occaisional, but may knock out the next gump run! Today it only happens
when
> > I run TestAllPackages.
> > Stephen
> >
> > - Original Message -
> > From: "Stephen Colebourne" <[EMAIL PROTECTED]>
> > To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>
> > Sent: Tuesday, December 02, 2003 12:46 AM
> > Subject: [collections] Race condition
> >
> >
> >
> >>Sadly there seems to be a race condition in one of the new classes/tests
> >>
> >>There was 1 failure:
> >>1)
testMapIteratorSet(TestFlat3Map.bulkTestMapIterator.testMapIteratorSet)
> >>junit.framework.AssertionFailedError: Map must not contain old value
> >>expected: but was:
> >> at
> >>
> >
> >
org.apache.commons.collections.iterators.AbstractTestMapIterator.testMapIter
> >
> >>atorSet(AbstractTestMapIterator.java:267)
> >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >> at
> >>
> >
> >
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
> >
> >>)
> >> at
> >>
> >
> >
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
> >
> >>.java:25)
> >> at org.apache.commons.collections.map.TestAll.main(TestAll.java:80)
> >>
> >>When I run with Eclipse debugger the error is in TestFlat3Map. When I
run
> >>without the debugger, the error is in TestHashedMap. And occaisionaly it
> >>works.
> >>
> >>I'm going to sleep, so I'll disable the test for the moment in case Gump
> >>runs. If anyone wants to play they're welcome - I'm guessing its the
test
> >>thats bad.
> >>
> >>Stephen
> >>
> >>
> >>
> >>-
> >>To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [collections] Race condition

[Phil Steitz]

Stephen,

I am not seeing these failures.  Did recent commits include a fix?  If so, 
where?  I am running the tests under maven, Sun Linux JDK 1.4.2.

Phil

Stephen Colebourne wrote:
HELP!
Anyone got any good ideas or tools to track this down. It is now very
occaisional, but may knock out the next gump run! Today it only happens when
I run TestAllPackages.
Stephen
- Original Message -
From: "Stephen Colebourne" <[EMAIL PROTECTED]>
To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>
Sent: Tuesday, December 02, 2003 12:46 AM
Subject: [collections] Race condition


Sadly there seems to be a race condition in one of the new classes/tests

There was 1 failure:
1) testMapIteratorSet(TestFlat3Map.bulkTestMapIterator.testMapIteratorSet)
junit.framework.AssertionFailedError: Map must not contain old value
expected: but was:
at
org.apache.commons.collections.iterators.AbstractTestMapIterator.testMapIter

atorSet(AbstractTestMapIterator.java:267)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39

)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl

.java:25)
at org.apache.commons.collections.map.TestAll.main(TestAll.java:80)
When I run with Eclipse debugger the error is in TestFlat3Map. When I run
without the debugger, the error is in TestHashedMap. And occaisionaly it
works.
I'm going to sleep, so I'll disable the test for the moment in case Gump
runs. If anyone wants to play they're welcome - I'm guessing its the test
thats bad.
Stephen



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collections/map ReferenceMap.java package.html

[scolebourne]

scolebourne2003/12/03 07:50:12

  Modified:collections/src/test/org/apache/commons/collections/map
TestAll.java
   collections/src/java/org/apache/commons/collections
ReferenceMap.java
   collections/src/java/org/apache/commons/collections/map
package.html
  Added:   collections/src/test/org/apache/commons/collections/map
TestReferenceMap.java
   collections/src/java/org/apache/commons/collections/map
ReferenceMap.java
  Log:
  Refactor ReferenceMap to map subpackage
  
  Revision  ChangesPath
  1.8   +3 -2  
jakarta-commons/collections/src/test/org/apache/commons/collections/map/TestAll.java
  
  Index: TestAll.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/collections/src/test/org/apache/commons/collections/map/TestAll.java,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- TestAll.java  3 Dec 2003 15:16:49 -   1.7
  +++ TestAll.java  3 Dec 2003 15:50:12 -   1.8
  @@ -86,6 +86,7 @@
   suite.addTest(TestFlat3Map.suite());
   suite.addTest(TestHashedMap.suite());
   suite.addTest(TestIdentityMap.suite());
  +suite.addTest(TestReferenceMap.suite());
   suite.addTest(TestStaticBucketMap.suite());
   
   suite.addTest(TestFixedSizeMap.suite());
  
  
  
  1.1  
jakarta-commons/collections/src/test/org/apache/commons/collections/map/TestReferenceMap.java
  
  Index: TestReferenceMap.java
  ===
  /*
   * $Header: 
/home/cvs/jakarta-commons/collections/src/test/org/apache/commons/collections/map/TestReferenceMap.java,v
 1.1 2003/12/03 15:50:12 scolebourne Exp $
   * 
   *
   * The Apache Software License, Version 1.1
   *
   * Copyright (c) 2001-2003 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 acknowledgement:
   *   "This product includes software developed by the
   *Apache Software Foundation (http://www.apache.org/)."
   *Alternately, this acknowledgement may appear in the software itself,
   *if and wherever such third-party acknowledgements 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 prior written permission. For written
   *permission, please contact [EMAIL PROTECTED]
   *
   * 5. Products derived from this software may not be called "Apache"
   *nor may "Apache" appear in their names without prior written
   *permission of the Apache Software Foundation.
   *
   * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
   * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
   * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
   * DISCLAIMED.  IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
   * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
   * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
   * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
   * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
   * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
   * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
   * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
   * SUCH DAMAGE.
   * 
   *
   * This software consists of voluntary contributions made by many
   * individuals on behalf of the Apache Software Foundation.  For more
   * information on the Apache Software Foundation, please see
   * .
   *
   */
  package org.apache.commons.collections.map;
  
  import java.lang.ref.WeakReference;
  import java.util.Map;
  
  import junit.framework.Test;
  
  import org.apache.commons.collections.BulkTest;
  
  /**
   * Tests for ReferenceMap. 
   * 
   * @version $Revision: 1.1 $ $Date: 2003/12/03 15:50:12 

DO NOT REPLY [Bug 25167] New: - NullPointerException in SocketClient.getRemoteAddress()

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25167

NullPointerException in SocketClient.getRemoteAddress()

   Summary: NullPointerException in SocketClient.getRemoteAddress()
   Product: Commons
   Version: 1.1.0
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Net
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Description: java program running overnight.  Unknown network conditions caused
a NullPointerException in the SocketClient class.  The client had previously
been connected to a remote host.  There was not a programmatic disconnect from
the remote client.  However, there _may_ have been network issues causing a
disconnect from the remote client.  

Stack trace:
java.lang.NullPointerException
at
org.apache.commons.net.SocketClient.getRemoteAddress(SocketClient.java:502)
at
com.hp.isee.perftest.harness.resources.TelnetKeepAlive.run(RemoteSystem.java:417)
at java.util.TimerThread.mainLoop(Unknown Source)
at java.util.TimerThread.run(Unknown Source)

Suggestion:
I think that a disconnected client should return a null value rather than throw
a NullPointerException.  I'd recommend changing line 502 of SocketClient.java from 

502 return _socket_.getInetAddress();

to 

502 if (_socket_ == null)
503 return null;
504 else
505  return _socket_.getInetAddress();

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons-sandbox/functor/src/test/org/apache/commons/functor/core/composite TestCompositeUnaryProcedure.java TestCompositeUnaryPredicate.java

[rwaldhoff]

rwaldhoff2003/12/03 07:24:46

  Modified:functor/src/test/org/apache/commons/functor/core/composite
TestCompositeUnaryProcedure.java
TestCompositeUnaryPredicate.java
  Log:
  add tests
  
  Revision  ChangesPath
  1.3   +8 -2  
jakarta-commons-sandbox/functor/src/test/org/apache/commons/functor/core/composite/TestCompositeUnaryProcedure.java
  
  Index: TestCompositeUnaryProcedure.java
  ===
  RCS file: 
/home/cvs/jakarta-commons-sandbox/functor/src/test/org/apache/commons/functor/core/composite/TestCompositeUnaryProcedure.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- TestCompositeUnaryProcedure.java  3 Dec 2003 01:07:36 -   1.2
  +++ TestCompositeUnaryProcedure.java  3 Dec 2003 15:24:46 -   1.3
  @@ -114,6 +114,12 @@
   // expected
   }
   try {
  +new CompositeUnaryProcedure(null,null);
  +fail("Expected NullPointerException");
  +} catch(NullPointerException e) {
  +// expected
  +}
  +try {
   new CompositeUnaryProcedure(NoOp.instance(),null);
   fail("Expected NullPointerException");
   } catch(NullPointerException e) {
  
  
  
  1.3   +8 -2  
jakarta-commons-sandbox/functor/src/test/org/apache/commons/functor/core/composite/TestCompositeUnaryPredicate.java
  
  Index: TestCompositeUnaryPredicate.java
  ===
  RCS file: 
/home/cvs/jakarta-commons-sandbox/functor/src/test/org/apache/commons/functor/core/composite/TestCompositeUnaryPredicate.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- TestCompositeUnaryPredicate.java  3 Dec 2003 01:07:36 -   1.2
  +++ TestCompositeUnaryPredicate.java  3 Dec 2003 15:24:46 -   1.3
  @@ -115,6 +115,12 @@
   // expected
   }
   try {
  +new CompositeUnaryPredicate(null,null);
  +fail("Expected NullPointerException");
  +} catch(NullPointerException e) {
  +// expected
  +}
  +try {
   new CompositeUnaryPredicate(Constant.truePredicate(),null);
   fail("Expected NullPointerException");
   } catch(NullPointerException e) {
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collections/map StaticBucketMap.java package.html

[scolebourne]

scolebourne2003/12/03 07:16:49

  Modified:collections/src/java/org/apache/commons/collections
StaticBucketMap.java
   collections/src/test/org/apache/commons/collections/map
TestAll.java
   collections/src/java/org/apache/commons/collections/map
package.html
  Added:   collections/src/test/org/apache/commons/collections/map
TestStaticBucketMap.java
   collections/src/java/org/apache/commons/collections/map
StaticBucketMap.java
  Log:
  Refactor StaticBucketMap to map subpackage
  
  Revision  ChangesPath
  1.13  +3 -2  
jakarta-commons/collections/src/java/org/apache/commons/collections/StaticBucketMap.java
  
  Index: StaticBucketMap.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/StaticBucketMap.java,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- StaticBucketMap.java  31 Aug 2003 17:26:44 -  1.12
  +++ StaticBucketMap.java  3 Dec 2003 15:16:49 -   1.13
  @@ -129,6 +129,7 @@
* iterations, or if you can make your own guarantees about how bulk 
* operations will affect the map.
*
  + * @deprecated Moved to map subpackage. Due to be removed in v4.0.
* @since Commons Collections 2.1
* @version $Revision$ $Date$
* 
  
  
  
  1.7   +6 -4  
jakarta-commons/collections/src/test/org/apache/commons/collections/map/TestAll.java
  
  Index: TestAll.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/collections/src/test/org/apache/commons/collections/map/TestAll.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- TestAll.java  2 Dec 2003 21:57:08 -   1.6
  +++ TestAll.java  3 Dec 2003 15:16:49 -   1.7
  @@ -83,11 +83,13 @@
   public static Test suite() {
   TestSuite suite = new TestSuite();
   
  -suite.addTest(TestFixedSizeMap.suite());
  -suite.addTest(TestFixedSizeSortedMap.suite());
   suite.addTest(TestFlat3Map.suite());
   suite.addTest(TestHashedMap.suite());
   suite.addTest(TestIdentityMap.suite());
  +suite.addTest(TestStaticBucketMap.suite());
  +
  +suite.addTest(TestFixedSizeMap.suite());
  +suite.addTest(TestFixedSizeSortedMap.suite());
   suite.addTest(TestLazyMap.suite());
   suite.addTest(TestLazySortedMap.suite());
   suite.addTest(TestListOrderedMap.suite());
  
  
  
  1.1  
jakarta-commons/collections/src/test/org/apache/commons/collections/map/TestStaticBucketMap.java
  
  Index: TestStaticBucketMap.java
  ===
  /*
   * $Header: 
/home/cvs/jakarta-commons/collections/src/test/org/apache/commons/collections/map/TestStaticBucketMap.java,v
 1.1 2003/12/03 15:16:49 scolebourne Exp $
   * 
   *
   * The Apache Software License, Version 1.1
   *
   * Copyright (c) 2001-2003 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 acknowledgement:
   *   "This product includes software developed by the
   *Apache Software Foundation (http://www.apache.org/)."
   *Alternately, this acknowledgement may appear in the software itself,
   *if and wherever such third-party acknowledgements 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 prior written permission. For written
   *permission, please contact [EMAIL PROTECTED]
   *
   * 5. Products derived from this software may not be called "Apache"
   *nor may "Apache" appear in their names without prior written
   *permission of the Apache Software Foundation.
   *
   * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
   * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
   * OF MERCHANTABILITY AND FITNESS FOR A PARTICU

cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collections/pairs package.html

[scolebourne]

scolebourne2003/12/03 07:15:16

  Added:   collections/src/java/org/apache/commons/collections/pairs
package.html
  Log:
  Update package description
  
  Revision  ChangesPath
  1.1  
jakarta-commons/collections/src/java/org/apache/commons/collections/pairs/package.html
  
  Index: package.html
  ===
  
  
  This package contains implementations of collection related data holding classes.
  
  The following data holders are included:
  
  Map Entry - various map entry implementations
  KeyValue - a key and value pair, without map entry semantics
  
  
  
  
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collections PriorityQueueUtils.java

[scolebourne]

scolebourne2003/12/03 06:39:42

  Modified:collections/src/java/org/apache/commons/collections
PriorityQueueUtils.java
  Log:
  Fix deprecation by referencing the correct BinaryHeap
  
  Revision  ChangesPath
  1.4   +3 -2  
jakarta-commons/collections/src/java/org/apache/commons/collections/PriorityQueueUtils.java
  
  Index: PriorityQueueUtils.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/PriorityQueueUtils.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- PriorityQueueUtils.java   16 Nov 2003 00:05:44 -  1.3
  +++ PriorityQueueUtils.java   3 Dec 2003 14:39:42 -   1.4
  @@ -57,6 +57,7 @@
*/
   package org.apache.commons.collections;
   
  +import org.apache.commons.collections.buffer.BinaryHeap;
   import org.apache.commons.collections.buffer.SynchronizedPriorityQueue;
   import org.apache.commons.collections.buffer.UnmodifiablePriorityQueue;
   
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[collections] pairs package name

[Stephen Colebourne]

The pairs package name is perhaps not quite right. I would like the package
to hold all non-collection data structure:
 - MapEntry
 - KeyValue
 - MultiKey

How about renaming the package to data?
(no backwards compatability issues)

Stephen


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons/collections/src/test/org/apache/commons/collections/bidimap TestUnmodifiableOrderedBidiMap.java TestUnmodifiableSortedBidiMap.java TestAll.java

[scolebourne]

scolebourne2003/12/03 06:03:35

  Modified:collections/src/java/org/apache/commons/collections/bidimap
package.html AbstractBidiMapDecorator.java
   collections/src/test/org/apache/commons/collections/bidimap
TestAll.java
  Added:   collections/src/java/org/apache/commons/collections/bidimap
UnmodifiableOrderedBidiMap.java
AbstractOrderedBidiMapDecorator.java
UnmodifiableSortedBidiMap.java
AbstractSortedBidiMapDecorator.java
   collections/src/test/org/apache/commons/collections/bidimap
TestUnmodifiableOrderedBidiMap.java
TestUnmodifiableSortedBidiMap.java
  Log:
  Add unmodifiable BidiMap decorators
  
  Revision  ChangesPath
  1.3   +8 -4  
jakarta-commons/collections/src/java/org/apache/commons/collections/bidimap/package.html
  
  Index: package.html
  ===
  RCS file: 
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/bidimap/package.html,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- package.html  3 Dec 2003 12:23:19 -   1.2
  +++ package.html  3 Dec 2003 14:03:35 -   1.3
  @@ -7,12 +7,16 @@
   
   The following implementations are provided in the package:
   
  -DualHash - uses two HashMaps to implement BidiMap
  -DualTree - uses two TreeMaps to implement SortedBidiMap
  -Tree - red-black tree implementation of OrderedBidiMap
  +DualHashBidiMap - uses two HashMaps to implement BidiMap
  +DualTreeBidiMap - uses two TreeMaps to implement SortedBidiMap
  +TreeBidiMap - red-black tree implementation of OrderedBidiMap
  +
  +
  +The following decorators are provided in the package:
  +
  +Unmodifiable - ensures the map cannot be altered
   

cvs commit: jakarta-commons/collections/src/test/org/apache/commons/collections/bidimap AbstractTestSortedBidiMap.java

[scolebourne]

scolebourne2003/12/03 06:02:49

  Modified:collections/src/test/org/apache/commons/collections/bidimap
AbstractTestSortedBidiMap.java
  Log:
  Fix tests to support unmodifiable test cases
  
  Revision  ChangesPath
  1.6   +20 -2 
jakarta-commons/collections/src/test/org/apache/commons/collections/bidimap/AbstractTestSortedBidiMap.java
  
  Index: AbstractTestSortedBidiMap.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/collections/src/test/org/apache/commons/collections/bidimap/AbstractTestSortedBidiMap.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- AbstractTestSortedBidiMap.java1 Dec 2003 22:34:54 -   1.5
  +++ AbstractTestSortedBidiMap.java3 Dec 2003 14:02:49 -   1.6
  @@ -156,6 +156,8 @@
   
   //---
   public void testBidiClearByHeadMap() {
  +if (isRemoveSupported() == false) return;
  +
   // extra test as other tests get complex
   SortedBidiMap sm = (SortedBidiMap) makeFullMap();
   Iterator it = sm.keySet().iterator();
  @@ -199,6 +201,8 @@
   
   //---
   public void testBidiRemoveByHeadMap() {
  +if (isRemoveSupported() == false) return;
  +
   // extra test as other tests get complex
   SortedBidiMap sm = (SortedBidiMap) makeFullMap();
   Iterator it = sm.keySet().iterator();
  @@ -239,6 +243,8 @@
   
   //---
   public void testBidiRemoveByHeadMapEntrySet() {
  +if (isRemoveSupported() == false) return;
  +
   // extra test as other tests get complex
   SortedBidiMap sm = (SortedBidiMap) makeFullMap();
   Iterator it = sm.keySet().iterator();
  @@ -318,6 +324,8 @@
   
   //---
   public void testBidiClearByTailMap() {
  +if (isRemoveSupported() == false) return;
  +
   // extra test as other tests get complex
   SortedBidiMap sm = (SortedBidiMap) makeFullMap();
   Iterator it = sm.keySet().iterator();
  @@ -363,6 +371,8 @@
   
   //---   
 
   public void testBidiRemoveByTailMap() {
  +if (isRemoveSupported() == false) return;
  +
   // extra test as other tests get complex
   SortedBidiMap sm = (SortedBidiMap) makeFullMap();
   Iterator it = sm.keySet().iterator();
  @@ -404,6 +414,8 @@
   
   //---
   public void testBidiRemoveByTailMapEntrySet() {
  +if (isRemoveSupported() == false) return;
  +
   // extra test as other tests get complex
   SortedBidiMap sm = (SortedBidiMap) makeFullMap();
   Iterator it = sm.keySet().iterator();
  @@ -490,6 +502,8 @@
   
   //---
   public void testBidiClearBySubMap() {
  +if (isRemoveSupported() == false) return;
  +
   // extra test as other tests get complex
   SortedBidiMap sm = (SortedBidiMap) makeFullMap();
   Iterator it = sm.keySet().iterator();
  @@ -543,6 +557,8 @@
   
   //---
   public void testBidiRemoveBySubMap() {
  +if (isRemoveSupported() == false) return;
  +
   // extra test as other tests get complex
   SortedBidiMap sm = (SortedBidiMap) makeFullMap();
   Iterator it = sm.keySet().iterator();
  @@ -585,6 +601,8 @@
   
   //---
   public void testBidiRemoveBySubMapEntrySet() {
  +if (isRemoveSupported() == false) return;
  +
   // extra test as other tests get complex
   SortedBidiMap sm = (SortedBidiMap) makeFullMap();
   Iterator it = sm.keySet().iterator();
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collections/bidimap AbstractBidiMapDecorator.java UnmodifiableBidiMap.java

[scolebourne]

scolebourne2003/12/03 04:59:37

  Modified:collections/src/test/org/apache/commons/collections/bidimap
AbstractTestBidiMap.java TestAll.java
  Added:   collections/src/test/org/apache/commons/collections/bidimap
TestUnmodifiableBidiMap.java
   collections/src/java/org/apache/commons/collections/bidimap
AbstractBidiMapDecorator.java
UnmodifiableBidiMap.java
  Log:
  Add unmodifiable BidiMap decorator
  
  Revision  ChangesPath
  1.6   +17 -3 
jakarta-commons/collections/src/test/org/apache/commons/collections/bidimap/AbstractTestBidiMap.java
  
  Index: AbstractTestBidiMap.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/collections/src/test/org/apache/commons/collections/bidimap/AbstractTestBidiMap.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- AbstractTestBidiMap.java  1 Dec 2003 22:49:00 -   1.5
  +++ AbstractTestBidiMap.java  3 Dec 2003 12:59:36 -   1.6
  @@ -92,7 +92,7 @@
   new Object[] { "value2", "key2" },
   new Object[] { "value3", "key3" }
   };
  -private final Object[][] entries;
  +protected final Object[][] entries;
   
   public AbstractTestBidiMap(String testName) {
   super(testName);
  @@ -149,6 +149,8 @@
   // BidiPut
   //---
   public void testBidiPut() {
  +if (isPutAddSupported() == false || isPutChangeSupported() == false) return;
  +
   BidiMap map = makeEmptyBidiMap();
   BidiMap inverse = map.inverseBidiMap();
   assertEquals(0, map.size());
  @@ -275,6 +277,8 @@
   
   //---
   public void testBidiClear() {
  +if (isRemoveSupported() == false) return;
  +
   BidiMap map = makeFullBidiMap();
   map.clear();
   assertTrue("Map was not cleared.", map.isEmpty());
  @@ -290,6 +294,8 @@
   
   //---
   public void testBidiRemove() {
  +if (isRemoveSupported() == false) return;
  +
   remove(makeFullBidiMap(), entries[0][0]);
   remove(makeFullBidiMap().inverseBidiMap(), entries[0][1]);
   
  @@ -325,6 +331,8 @@
   
   //---
   public void testBidiRemoveByKeySet() {
  +if (isRemoveSupported() == false) return;
  +
   removeByKeySet(makeFullBidiMap(), entries[0][0], entries[0][1]);
   removeByKeySet(makeFullBidiMap().inverseBidiMap(), entries[0][1], 
entries[0][0]);
   }
  @@ -345,6 +353,8 @@
   
   //---
   public void testBidiRemoveByEntrySet() {
  +if (isRemoveSupported() == false) return;
  +
   removeByEntrySet(makeFullBidiMap(), entries[0][0], entries[0][1]);
   removeByEntrySet(makeFullBidiMap().inverseBidiMap(), entries[0][1], 
entries[0][0]);
   }
  @@ -365,6 +375,7 @@
   !map.inverseBidiMap().containsKey(value));
   }
   
  +//---
   public BulkTest bulkTestMapEntrySet() {
   return new TestBidiMapEntrySet();
   }
  @@ -447,6 +458,9 @@
   }
   public BidiMap makeFullBidiMap() {
   return main.makeFullBidiMap().inverseBidiMap();
  +}
  +public Map makeFullMap() {
  +return ((BidiMap) main.makeFullMap()).inverseBidiMap();
   }
   public Object[] getSampleKeys() {
   return main.getSampleValues();
  
  
  
  1.2   +4 -2  
jakarta-commons/collections/src/test/org/apache/commons/collections/bidimap/TestAll.java
  
  Index: TestAll.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/collections/src/test/org/apache/commons/collections/bidimap/TestAll.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- TestAll.java  16 Nov 2003 20:35:46 -  1.1
  +++ TestAll.java  3 Dec 2003 12:59:36 -   1.2
  @@ -87,6 +87,8 @@
   suite.addTest(TestDualTreeBidiMap.suite());
   suite.addTest(TestTreeBidiMap.suite());
   
  +suite.addTest(TestUnmodifiableBidiMap.suite());
  +
   return suite;
   }
   
  
  
  
  1.1  
jakarta-commons/collections/src/test/org/apache/commons/collections/bidimap/TestUnmodifiableBidiMap.java
  
  Index: TestUnmodifiableBidiMap.java
  ===
  /*
   * $Header: 
/home/cvs/jakarta-commons/collect

[Jelly] Anyone cares in patches?

[Jörg Schaible]

Hi, 

since I did not see any a lot of traffic for Jelly this year at all and the docs for 
the tutorial are out-of-date I ask myself if anybody cares of patches to Jelly at all 
(http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-98)?

Regards,
Jörg


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collections/bag UnmodifiableSortedBag.java UnmodifiableBag.java

[scolebourne]

scolebourne2003/12/03 04:27:37

  Modified:collections/src/java/org/apache/commons/collections/list
UnmodifiableList.java
   collections/src/java/org/apache/commons/collections/buffer
UnmodifiableBuffer.java
UnmodifiablePriorityQueue.java
   collections/src/java/org/apache/commons/collections/map
UnmodifiableSortedMap.java UnmodifiableMap.java
UnmodifiableOrderedMap.java
   collections/src/java/org/apache/commons/collections/iterators
UnmodifiableListIterator.java
UnmodifiableMapIterator.java
UnmodifiableOrderedMapIterator.java
UnmodifiableIterator.java
   collections/src/java/org/apache/commons/collections/set
UnmodifiableSortedSet.java UnmodifiableSet.java
   collections/src/java/org/apache/commons/collections
BeanMap.java
   collections/src/java/org/apache/commons/collections/collection
UnmodifiableBoundedCollection.java
UnmodifiableCollection.java
   collections/src/java/org/apache/commons/collections/bag
UnmodifiableSortedBag.java UnmodifiableBag.java
  Added:   collections/src/java/org/apache/commons/collections/map
UnmodifiableEntrySet.java
  Log:
  Update and make consistent the Unmodifiable decorators
  
  Revision  ChangesPath
  1.3   +4 -25 
jakarta-commons/collections/src/java/org/apache/commons/collections/list/UnmodifiableList.java
  
  Index: UnmodifiableList.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/list/UnmodifiableList.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- UnmodifiableList.java 3 Dec 2003 11:19:10 -   1.2
  +++ UnmodifiableList.java 3 Dec 2003 12:27:36 -   1.3
  @@ -74,7 +74,7 @@
* 
* @author Stephen Colebourne
*/
  -public class UnmodifiableList extends AbstractListDecorator implements Unmodifiable 
{
  +public final class UnmodifiableList extends AbstractListDecorator implements 
Unmodifiable {
   
   /**
* Factory method to create an unmodifiable list.
  @@ -96,19 +96,10 @@
* @param list  the list to decorate, must not be null
* @throws IllegalArgumentException if list is null
*/
  -protected UnmodifiableList(List list) {
  +private UnmodifiableList(List list) {
   super(list);
   }
   
  -/**
  - * Gets the list being decorated.
  - * 
  - * @return the list being decorated
  - */
  -protected List getList() {
  -return (List) getCollection();
  -}
  -
   //---
   public Iterator iterator() {
   return UnmodifiableIterator.decorate(getCollection().iterator());
  @@ -139,18 +130,6 @@
   }
   
   //---
  -public Object get(int index) {
  -return getList().get(index);
  -}
  -
  -public int indexOf(Object object) {
  -return getList().indexOf(object);
  -}
  -
  -public int lastIndexOf(Object object) {
  -return getList().lastIndexOf(object);
  -}
  -
   public ListIterator listIterator() {
   return UnmodifiableListIterator.decorate(getList().listIterator());
   }
  
  
  
  1.3   +4 -4  
jakarta-commons/collections/src/java/org/apache/commons/collections/buffer/UnmodifiableBuffer.java
  
  Index: UnmodifiableBuffer.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/buffer/UnmodifiableBuffer.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- UnmodifiableBuffer.java   3 Dec 2003 11:19:10 -   1.2
  +++ UnmodifiableBuffer.java   3 Dec 2003 12:27:36 -   1.3
  @@ -72,7 +72,7 @@
* 
* @author Stephen Colebourne
*/
  -public class UnmodifiableBuffer extends AbstractBufferDecorator implements 
Unmodifiable {
  +public final class UnmodifiableBuffer extends AbstractBufferDecorator implements 
Unmodifiable {
   
   /**
* Factory method to create an unmodifiable buffer.
  @@ -94,7 +94,7 @@
* @param buffer  the buffer to decorate, must not be null
* @throws IllegalArgumentException if buffer is null
*/
  -protected UnmodifiableBuffer(Buffer buffer) {
  +private UnmodifiableBuffer(Buffer buffer) {
   super(buffer);
   }
   
  
  
  
  1.3   +8 -7  
jakarta-commons/collections/src/

RE: Jelly: Build from CVS fails a lot of unit tests

[Jörg Schaible]

Just as side note: This happens with latest commons-lang-2.0 version, using the 
referenced commons-lang-1.0 everything is ok.

Jörg Schaible wrote on Tuesday, November 25, 2003 12:11 PM:
> Hello Jelly developers,
> 
> if I build Jelly with the sources from CSV the build with
> maven fails because of a lot JUnit errors (see below). Did I
> miss something?
> 
> Regards,
> Jörg
> 
> 
> test:test:
> [junit] Running org.apache.commons.jelly.core.TestArgTag
> [junit] Tests run: 16, Failures: 0, Errors: 0, Time
> elapsed: 0,46 sec
> [junit] Running org.apache.commons.jelly.core.TestChooseTag
> [junit] Tests run: 1, Failures: 0, Errors: 1, Time
> elapsed: 0,781 sec
> [junit] [ERROR] TEST
> org.apache.commons.jelly.core.TestChooseTag FAILED
> [junit] Running org.apache.commons.jelly.core.TestIncludeTag
> [junit] Tests run: 4, Failures: 0, Errors: 0, Time
> elapsed: 0,711 sec
> [junit] Running org.apache.commons.jelly.core.TestInvokeStaticTag
> [junit] Tests run: 3, Failures: 0, Errors: 0, Time
> elapsed: 0,791 sec
> [junit] Running org.apache.commons.jelly.core.TestInvokeTag
> [junit] Tests run: 4, Failures: 0, Errors: 3, Time
> elapsed: 0,871 sec
> [junit] [ERROR] TEST
> org.apache.commons.jelly.core.TestInvokeTag FAILED
> [junit] Running org.apache.commons.jelly.core.TestNewTag
> [junit] Tests run: 8, Failures: 0, Errors: 5, Time
> elapsed: 0,921 sec
> [junit] [ERROR] TEST
> org.apache.commons.jelly.core.TestNewTag FAILED
> [junit] Running org.apache.commons.jelly.core.TestSwitchTag
> [junit] Tests run: 10, Failures: 0, Errors: 0, Time
> elapsed: 0,921 sec
> [junit] Running org.apache.commons.jelly.expression.TestDynaBeans
> [junit] Tests run: 1, Failures: 0, Errors: 0, Time
> elapsed: 0,49 sec
> [junit] Running
> org.apache.commons.jelly.expression.TestExpressions
> [junit] Tests run: 3, Failures: 0, Errors: 3, Time
> elapsed: 0,461 sec
> [junit] [ERROR] TEST
> org.apache.commons.jelly.expression.TestExpressions FAILED
> [junit] Running org.apache.commons.jelly.impl.TestTagLibraryResolver
> [junit] Tests run: 1, Failures: 0, Errors: 0, Time
> elapsed: 0,381 sec
> [junit] Running org.apache.commons.jelly.test.impl.TestEmbedded
> [junit] Tests run: 2, Failures: 0, Errors: 2, Time
> elapsed: 0,691 sec
> [junit] [ERROR] TEST
> org.apache.commons.jelly.test.impl.TestEmbedded FAILED
> [junit] Running org.apache.commons.jelly.test.xml.TestCData
> [junit] Tests run: 1, Failures: 0, Errors: 1, Time
> elapsed: 0,701 sec
> [junit] [ERROR] TEST
> org.apache.commons.jelly.test.xml.TestCData FAILED
> [junit] Running
> org.apache.commons.jelly.test.xml.TestDefaultNamespaceFilter
> [junit] Tests run: 2, Failures: 0, Errors: 0, Time
> elapsed: 0,792 sec
> [junit] Running
> org.apache.commons.jelly.test.xml.TestDummyXMLOutput
> [junit] Tests run: 1, Failures: 0, Errors: 0, Time
> elapsed: 0,671 sec
> [junit] Running
> org.apache.commons.jelly.test.xml.TestNonexistentTags
> [junit] Tests run: 1, Failures: 0, Errors: 0, Time
> elapsed: 0,671 sec
> [junit] Running
> org.apache.commons.jelly.test.xml.TestXMLParserCache
> [junit] Tests run: 2, Failures: 0, Errors: 0, Time
> elapsed: 0,891 sec
> [junit] Running
> org.apache.commons.jelly.test.xml.TestXMLValidation
> [junit] Tests run: 3, Failures: 0, Errors: 0, Time
> elapsed: 0,821 sec
> [junit] Running org.apache.commons.jelly.TestCoreTags
> [junit] Tests run: 3, Failures: 0, Errors: 3, Time
> elapsed: 0,761 sec
> [junit] [ERROR] TEST org.apache.commons.jelly.TestCoreTags FAILED
> [junit] Running org.apache.commons.jelly.TestJelly
> [junit] this should always workthis should always
> workthis should always workthis should always work
> [junit]
> [junit] Created a new bean:
> [EMAIL PROTECTED];city=London]
> [junit] [junit]
> [junit]
> [junit] Created a new bean:
> [EMAIL PROTECTED];city=London]
> [junit] [junit]
> [junit]
> 
> [junit] Created a new bean:
> [EMAIL PROTECTED];city=Atlanta] 
> [junit] [junit] Tests run: 14, Failures: 0, Errors:
> 0, Time elapsed: 0,291 sec [junit] Running
> org.apache.commons.jelly.TestJellyContext [junit] Tests run: 1,
> Failures: 0, Errors: 0, Time 
> elapsed: 0,411 sec
> [junit] Running org.apache.commons.jelly.TestTrim
> [junit] Tests run: 3, Failures: 0, Errors: 3, Time
> elapsed: 0,39 sec
> [junit] [ERROR] TEST org.apache.commons.jelly.TestTrim FAILED
> 
> BUILD FAILED
> File.. file:/C:/Dokumente und
> Einstellungen/jos/.maven/plugins/maven-test-plugin-1.4/
> Element... fail
> Line.. 130
> Column 54
> There were test failures.
> Total time: 29 seconds
> Finished at: Tue Nov 25 12:08:11 CET 2003
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PR

cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collections/buffer package.html

[scolebourne]

scolebourne2003/12/03 04:23:19

  Modified:collections/src/java/org/apache/commons/collections/collection
package.html
   collections/src/java/org/apache/commons/collections/bidimap
package.html
   collections/src/java/org/apache/commons/collections/bag
package.html
   collections/src/java/org/apache/commons/collections/buffer
package.html
  Log:
  Improve package html
  
  Revision  ChangesPath
  1.2   +1 -5  
jakarta-commons/collections/src/java/org/apache/commons/collections/collection/package.html
  
  Index: package.html
  ===
  RCS file: 
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/collection/package.html,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- package.html  16 Nov 2003 00:05:47 -  1.1
  +++ package.html  3 Dec 2003 12:23:19 -   1.2
  @@ -2,11 +2,7 @@
   
   This package contains implementations of the Collection interface.
   
  -The implementations are in the form of direct implementations and decorators.
  -A decorator wraps another implementation of the interface to add some
  -specific additional functionality.
  -
  -The following implementations are provided in the package:
  +The following decorators are provided in the package:
   
   Synchronized - synchronizes method access for multi-threaded environments
   Unmodifiable - ensures the collection cannot be altered
  
  
  
  1.2   +3 -4  
jakarta-commons/collections/src/java/org/apache/commons/collections/bidimap/package.html
  
  Index: package.html
  ===
  RCS file: 
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/bidimap/package.html,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- package.html  16 Nov 2003 20:35:46 -  1.1
  +++ package.html  3 Dec 2003 12:23:19 -   1.2
  @@ -1,10 +1,9 @@
   
   
   This package contains implementations of the BidiMap, OrderedBidiMap and 
SortedBidiMap interfaces.
  -
  -The implementations are in the form of direct implementations and decorators.
  -A decorator wraps another implementation of the interface to add some
  -specific additional functionality.
  +A BidiMap is an extension to Map that allows keys and values to be looked up with 
equal ease.
  +One example usage is a system communicating to a legacy datasource that must 
convert codes
  +from the new format to the old format and vice versa.
   
   The following implementations are provided in the package:
   
  
  
  
  1.3   +0 -4  
jakarta-commons/collections/src/java/org/apache/commons/collections/bag/package.html
  
  Index: package.html
  ===
  RCS file: 
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/bag/package.html,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- package.html  2 Dec 2003 23:39:48 -   1.2
  +++ package.html  3 Dec 2003 12:23:19 -   1.3
  @@ -2,10 +2,6 @@
   
   This package contains implementations of the Bag and SortedBag interfaces.
   
  -The implementations are in the form of direct implementations and decorators.
  -A decorator wraps another implementation of the interface to add some
  -specific additional functionality.
  -
   The following implementations are provided in the package:
   
   HashBag - implementation that uses a HashMap to store the data
  
  
  
  1.4   +0 -4  
jakarta-commons/collections/src/java/org/apache/commons/collections/buffer/package.html
  
  Index: package.html
  ===
  RCS file: 
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/buffer/package.html,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- package.html  3 Dec 2003 01:05:31 -   1.3
  +++ package.html  3 Dec 2003 12:23:19 -   1.4
  @@ -2,10 +2,6 @@
   
   This package contains implementations of the Buffer and PriorityQueue interfaces.
   
  -The implementations are in the form of direct implementations and decorators.
  -A decorator wraps another implementation of the interface to add some
  -specific additional functionality.
  -
   The following implementations are provided in the package:
   
   BinaryHeap - implements both Buffer and PriorityQueue
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collections/set ListOrderedSet.java

[scolebourne]

scolebourne2003/12/03 03:37:44

  Modified:collections/src/java/org/apache/commons/collections/decorators
OrderedSet.java CompositeCollection.java
SetList.java
   collections/src/java/org/apache/commons/collections/list
SetUniqueList.java
   collections/src/java/org/apache/commons/collections/iterators
IteratorChain.java CollatingIterator.java
   collections/src/java/org/apache/commons/collections
SequencedHashMap.java SetUtils.java MapUtils.java
DefaultMapBag.java CollectionUtils.java
BeanMap.java
   collections/src/java/org/apache/commons/collections/collection
CompositeCollection.java
   collections/src/java/org/apache/commons/collections/set
ListOrderedSet.java
  Log:
  Use the Unmodifiable decorators everywhere
  
  Revision  ChangesPath
  1.6   +5 -4  
jakarta-commons/collections/src/java/org/apache/commons/collections/decorators/OrderedSet.java
  
  Index: OrderedSet.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/decorators/OrderedSet.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- OrderedSet.java   16 Nov 2003 00:39:37 -  1.5
  +++ OrderedSet.java   3 Dec 2003 11:37:44 -   1.6
  @@ -59,12 +59,13 @@
   
   import java.util.ArrayList;
   import java.util.Collection;
  -import java.util.Collections;
   import java.util.HashSet;
   import java.util.Iterator;
   import java.util.List;
   import java.util.Set;
   
  +import org.apache.commons.collections.list.UnmodifiableList;
  +
   /**
* Decorates a Set to ensure that the order of addition
* is retained and used by the iterator.
  @@ -155,7 +156,7 @@
* @return an unmodifiable list view
*/
   public List asList() {
  -return Collections.unmodifiableList(setOrder);
  +return UnmodifiableList.decorate(setOrder);
   }
   
   //---
  
  
  
  1.3   +4 -4  
jakarta-commons/collections/src/java/org/apache/commons/collections/decorators/CompositeCollection.java
  
  Index: CompositeCollection.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/decorators/CompositeCollection.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- CompositeCollection.java  16 Nov 2003 00:39:37 -  1.2
  +++ CompositeCollection.java  3 Dec 2003 11:37:44 -   1.3
  @@ -61,11 +61,11 @@
   import java.util.ArrayList;
   import java.util.Arrays;
   import java.util.Collection;
  -import java.util.Collections;
   import java.util.Iterator;
   
   import org.apache.commons.collections.IteratorUtils;
   import org.apache.commons.collections.iterators.IteratorChain;
  +import org.apache.commons.collections.list.UnmodifiableList;
   
   /**
* A Collection implementation that decorates other collections
  @@ -416,7 +416,7 @@
* @return Unmodifiable collection of all collections in this composite.
*/
   public Collection getCollections() {
  -return Collections.unmodifiableList(Arrays.asList(this.all));
  +return UnmodifiableList.decorate(Arrays.asList(this.all));
   }
   
   //---
  
  
  
  1.5   +5 -4  
jakarta-commons/collections/src/java/org/apache/commons/collections/decorators/SetList.java
  
  Index: SetList.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/decorators/SetList.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- SetList.java  16 Nov 2003 00:39:37 -  1.4
  +++ SetList.java  3 Dec 2003 11:37:44 -   1.5
  @@ -59,13 +59,14 @@
   
   import java.util.ArrayList;
   import java.util.Collection;
  -import java.util.Collections;
   import java.util.HashSet;
   import java.util.Iterator;
   import java.util.List;
   import java.util.ListIterator;
   import java.util.Set;
   
  +import org.apache.commons.collections.set.UnmodifiableSet;
  +
   /**
* SetList combines the List and Set interfaces
* in one implementation.
  @@ -142,7 +143,7 @@
* @return an unmodifiable set view
*/
   public Set asSet() {
  -return Collections.unmodifiableSet(set);
  +return UnmodifiableSet.decorate(set);
   }
   
   //---
  
  
  
  1.2   

cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collections/set UnmodifiableSet.java UnmodifiableSortedSet.java

[scolebourne]

scolebourne2003/12/03 03:19:10

  Modified:collections/src/test/org/apache/commons/collections/list
TestUnmodifiableList.java
   collections/src/java/org/apache/commons/collections/list
UnmodifiableList.java
   collections/src/test/org/apache/commons/collections/set
AbstractTestSortedSet.java
TestUnmodifiableSortedSet.java TestAll.java
   collections/src/test/org/apache/commons/collections/collection
TestAll.java
   collections/src/java/org/apache/commons/collections/buffer
UnmodifiablePriorityQueue.java
UnmodifiableBuffer.java
   collections/src/java/org/apache/commons/collections/bag
UnmodifiableSortedBag.java UnmodifiableBag.java
AbstractMapBag.java
   collections/src/java/org/apache/commons/collections/collection
UnmodifiableCollection.java
   collections/src/java/org/apache/commons/collections/set
UnmodifiableSet.java UnmodifiableSortedSet.java
  Added:   collections/src/test/org/apache/commons/collections/set
TestUnmodifiableSet.java
   collections/src/test/org/apache/commons/collections/collection
TestUnmodifiableCollection.java
  Log:
  Update and make consistent the Unmodifiable decorators
  
  Revision  ChangesPath
  1.4   +10 -11
jakarta-commons/collections/src/test/org/apache/commons/collections/list/TestUnmodifiableList.java
  
  Index: TestUnmodifiableList.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/collections/src/test/org/apache/commons/collections/list/TestUnmodifiableList.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- TestUnmodifiableList.java 18 Nov 2003 22:37:14 -  1.3
  +++ TestUnmodifiableList.java 3 Dec 2003 11:19:10 -   1.4
  @@ -65,8 +65,6 @@
   import junit.framework.Test;
   import junit.framework.TestSuite;
   
  -import org.apache.commons.collections.map.TestPredicatedSortedMap;
  -
   /**
* Extension of [EMAIL PROTECTED] AbstractTestList} for exercising the 
* [EMAIL PROTECTED] UnmodifiableList} implementation.
  @@ -76,7 +74,7 @@
* 
* @author Phil Steitz
*/
  -public class TestUnmodifiableList extends AbstractTestList{
  +public class TestUnmodifiableList extends AbstractTestList {
   
   public TestUnmodifiableList(String testName) {
   super(testName);
  @@ -87,11 +85,11 @@
   }
   
   public static void main(String args[]) {
  -String[] testCaseName = { TestPredicatedSortedMap.class.getName()};
  +String[] testCaseName = { TestUnmodifiableList.class.getName()};
   junit.textui.TestRunner.main(testCaseName);
   }
  -
  - //---   
  +
  +//---
   public List makeEmptyList() {
   return UnmodifiableList.decorate(new ArrayList());
   }
  @@ -112,8 +110,9 @@
   
   public boolean isRemoveSupported() {
   return false;
  -}   
  -//   
  +}
  +
  +//---
   protected UnmodifiableList list = null;
   protected ArrayList array = null;
   
  @@ -209,4 +208,4 @@
   // expected
   }
   }
  -}
  \ No newline at end of file
  +}
  
  
  
  1.2   +39 -9 
jakarta-commons/collections/src/java/org/apache/commons/collections/list/UnmodifiableList.java
  
  Index: UnmodifiableList.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/list/UnmodifiableList.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- UnmodifiableList.java 16 Nov 2003 00:05:47 -  1.1
  +++ UnmodifiableList.java 3 Dec 2003 11:19:10 -   1.2
  @@ -58,12 +58,13 @@
   package org.apache.commons.collections.list;
   
   import java.util.Collection;
  +import java.util.Iterator;
   import java.util.List;
   import java.util.ListIterator;
   
  -import org.apache.commons.collections.IteratorUtils;
   import org.apache.commons.collections.Unmodifiable;
  -import org.apache.commons.collections.collection.UnmodifiableCollection;
  +import org.apache.commons.collections.iterators.UnmodifiableIterator;
  +import org.apache.commons.collections.iterators.UnmodifiableListIterator;
   
   /**
* Decorates another List to ensure it can't be altered.
  @@ -73,7 +74,7 @@

cvs commit: jakarta-commons/collections/src/test/org/apache/commons/collections/list TestPredicatedList.java

[scolebourne]

scolebourne2003/12/03 03:17:36

  Modified:collections/src/test/org/apache/commons/collections/list
TestPredicatedList.java
  Log:
  File layout
  
  Revision  ChangesPath
  1.4   +4 -4  
jakarta-commons/collections/src/test/org/apache/commons/collections/list/TestPredicatedList.java
  
  Index: TestPredicatedList.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/collections/src/test/org/apache/commons/collections/list/TestPredicatedList.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- TestPredicatedList.java   18 Nov 2003 22:37:14 -  1.3
  +++ TestPredicatedList.java   3 Dec 2003 11:17:36 -   1.4
  @@ -75,7 +75,7 @@
* 
* @author Phil Steitz
*/
  -public class TestPredicatedList extends AbstractTestList{
  +public class TestPredicatedList extends AbstractTestList {
   
   public TestPredicatedList(String testName) {
   super(testName);
  @@ -183,4 +183,4 @@
list.contains("three"));   
   }   
   
  -}
  \ No newline at end of file
  +}
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 25156] - Enhance error message for " org.apache.commons.logging.impl.Log4JLogger does not implement Log"

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25156

Enhance error message for " org.apache.commons.logging.impl.Log4JLogger does not 
implement Log"





--- Additional Comments From [EMAIL PROTECTED]  2003-12-03 10:40 ---
removed commons-logging.jar, left tomcat1.27/commons/lib/commons-logging-api.jar

and now it works again - no clue whether this is a recommendable setup or not???

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [digester] variable expansion

[ASHWIN Suresh]

Sorry to jump in to this thread this way, and perhaps it is too late now.
But, have the people here considered using the term "resolve"
for this concept?

Perhaps the interface could be named Resolver, with the method resolve().

I can think of ${foo} > xyz as resolving the definition rather than simple
substitution,
thow at a lower level of abstraction, it is substitution.

If this has been considered and vetoed, please ignore my email.

One more point:

> The spelling "substituter" feels more natural to me than 
> "substitutor".
> 
> cf.:
> to write --> writer
> to drive --> driver
> to expand --> expander


For Latinate words, the pattern is usually -or.
Constructor, translator, delegator, etc.
Whenever, the agent form is formed out of removal of -ion, the preferred
suffix is -or.
Thus, the more appropriate form is substitutor.
Again, perhaps this was already discussed.

Ash





> -Original Message-
> From: Simon Kitching [mailto:[EMAIL PROTECTED]
> Sent: Thursday, December 04, 2003 09:18
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: [digester] variable expansion
> 
> 
> Hi Robert,
> 
> I think the code committed is just fine.
> 
> I like the versatile "Substitutor" interface; I can imagine 
> all sorts of
> uses for the ability to arbitrarily manipulate attribute 
> values and body
> text before rules see them other than just var expansion.
> 
> I also like the separation of this code out into a package, with only
> the Substitutor interface in the main code.
> 
> Some *very* minor comments: 
> 
> --
> 
> In VariableSubstitutor, you use lazy creation for variableAttributes.
> I'm not sure there is much point to that. Given that the user 
> has set up
> var expansion in the first place, the object will almost certainly be
> created sometime. However the existing code has to evaluate an
> if-statement on each call to determine if the object already exists. I
> think it also makes the code more complex than it needs to be. Why not
> create it in the constructor as soon as it is known if there is an
> attributeExpander or not?
> 
> --
> 
> I think a comment is needed in the Substitutor "interface" specifying
> that Digester guarantees never to hold the return value of the
> substitute(Attributes) method past the next call to the method. It is
> this behaviour that allows a single VariableAttributes object to be
> reused by the VariableSubstitutor. This behaviour was obvious before,
> when VariableAttributes was directly invoked from the Digester's
> startElement method, but probably needs to be explicitly 
> documented now.
> 
> --
> 
> You mention that you were considering whether it is necessary to have
> Remy's VarExpander implementation as well as the 
> MultiVariableExpander.
> While it would be a shame to discard Remy's work, I don't see much
> benefit from having an additional implementation.
> 
> The MultiVariableExpander does:
> for(int i=0; i param = expand(
> param, 
> (String) markers.get(i), 
> (Map) sources.get(i));
> }
> return param;
> 
> The call to "expand" in the loop does exactly the same work as an
> implementation that supports only "${foo}" would do.
> 
> The overhead of looping once (ie nEntries=1) is trivial. The 
> overhead of
> fetching the marker and map from ArrayLists and casting them 
> is slightly
> higher, but still pretty small I think. That's the only performance
> difference I can see from an implementation customised for ant-like
> variables only. Oh - and avoiding one string concatenation in 
> the expand
> method ("$" + "{").
> 
> The API would be *very* slightly simpler: setSource(map) rather than
> addSource("$", map). I think this is more than offset by the 
> complexity
> of having multiple VarExpander implementations to choose from.
> 
> If the consensus is that the MultiVariableExpander is ok to 
> use for the
> simple case too, then it would probably make sense to rename it (eg
> BaseVariableExpander).
> 
> --
> 
> The spelling "substituter" feels more natural to me than 
> "substitutor".
> 
> cf.:
> to write --> writer
> to drive --> driver
> to expand --> expander
> 
> 
> Cheers,
> 
> Simon
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[digester] variable expansion

[Simon Kitching]

Hi Robert,

I think the code committed is just fine.

I like the versatile "Substitutor" interface; I can imagine all sorts of
uses for the ability to arbitrarily manipulate attribute values and body
text before rules see them other than just var expansion.

I also like the separation of this code out into a package, with only
the Substitutor interface in the main code.

Some *very* minor comments: 

--

In VariableSubstitutor, you use lazy creation for variableAttributes.
I'm not sure there is much point to that. Given that the user has set up
var expansion in the first place, the object will almost certainly be
created sometime. However the existing code has to evaluate an
if-statement on each call to determine if the object already exists. I
think it also makes the code more complex than it needs to be. Why not
create it in the constructor as soon as it is known if there is an
attributeExpander or not?

--

I think a comment is needed in the Substitutor "interface" specifying
that Digester guarantees never to hold the return value of the
substitute(Attributes) method past the next call to the method. It is
this behaviour that allows a single VariableAttributes object to be
reused by the VariableSubstitutor. This behaviour was obvious before,
when VariableAttributes was directly invoked from the Digester's
startElement method, but probably needs to be explicitly documented now.

--

You mention that you were considering whether it is necessary to have
Remy's VarExpander implementation as well as the MultiVariableExpander.
While it would be a shame to discard Remy's work, I don't see much
benefit from having an additional implementation.

The MultiVariableExpander does:
for(int i=0; i writer
to drive --> driver
to expand --> expander


Cheers,

Simon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 25156] New: - Enhance error message for " org.apache.commons.logging.impl.Log4JLogger does not implement Log"

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25156

Enhance error message for " org.apache.commons.logging.impl.Log4JLogger does not 
implement Log"

   Summary: Enhance error message for "
org.apache.commons.logging.impl.Log4JLogger does not
implement Log"
   Product: Commons
   Version: 1.0 Beta 1
  Platform: All
   URL: http://marc.theaimsgroup.com/?l=jakarta-commons-
user&m=106477725521034&w=2
OS/Version: All
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Logging
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


After moving from struts1.0 to struts1.1 I got the same error message as in the
above mailing list discussion thread.

Couldn't the error message contain the names of the two jar files?
Even better if it hinted on what to do or provided a link to an explanation page!

http://jakarta.apache.org/commons/logging/userguide.html#Configuring%20the%20Logger%20Implementation
didn't really provide any help?

So shall I remove the 
-rwxr-xr-x1 root root   218864 Dec  2 15:37 WEB-INF/lib/log4j.jar
or the 
-rw-r--r--1 root root31605 Dec  2 16:05
WEB-INF/lib/commons-logging.jar

Since all went well with log4j so far and the file is bigger, I am inclined to
dump commons-logging.jar.
On the other hand, since I am a new user of commons-dbcp-1.1.jar, that one may
rely on its own logger - so perhaps I will run into trouble due to that?
Anyway, help would be highly appreciated!

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [DBUtils] Extending QueryLoader...

[Juozas Baliuka]

Hernan Silberman wrote:

--- Hernan Silberman <[EMAIL PROTECTED]> wrote:
   

Hello,

I'm working on an application that uses "Named Queries" much like the 
DBUtils QueryLoader class reads in from a Java properties file.  The
queries in 
my application are stored in a relational database on the server side
and I was 
hoping I could extend QueryLoader so it fetched the NAME/SQL pairs in an

application-specific way, something like this:

public synchronized Map load(DataSource aDS) throws IOException;
public synchronized void unload(DataSource aDS);
I'm new to DBUtils, and figured I'd ask before trying to extend this
class in my 
code to accomodate something like the two methods above.  Is this a sane
thing 
to do?  I won't get exactly what I want by extending this class, because
I don't 
need the properties file versions of load and unload.  Should I just
create an 
alternate app-specific QueryLoader, or am I not seeing a better way of 
leveraging the existing QueryLoader class?
 

QueryLoader isn't used by other DbUtils classes; it's just a standalone
helper class that loads queries from properties files.  So, you won't gain
anything by subclassing it and replacing it with a DB lookup.
David
   



Thanks for the response.  Keeping a registry of named queries seems like a 
common thing to do and I see lots of utility in having a helper class like 
QueryLoader to do it with.  I was hoping I could easily change QueryLoader's 
behavior so it would look for it's name/query mapping somewhere other than a 
properties file, but alas, it's such a simple problem it's no big deal to handle 
this in my own code with another class.
 

I have used  property files to store queries, but I found it is much 
more easy to find string in java code than in file, then I need to 
change query for performance tuning or to fix bug (stack trace can help 
to find query in code). I use DbUtils fork myself ( http://voruta.sf.net 
) and looks like it is better way, but it has the same problems with 
type and name mapping for java beans.

On another note isn't it risky to return a reference to queryMap below without 
first wrapping it in Collections.unmodifiableMap( queryMap ) ?  I lack trust.

public synchronized Map load(String path) throws IOException {
   Map queryMap = (Map) this.queries.get(path);
   if (queryMap == null) {
   queryMap = this.loadQueries(path);
   this.queries.put(path, queryMap);
   }
   return queryMap;
}
thanks...
hernan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]