> Costin Manolache wrote:
> >
> > What's wrong with having multiple thread pools or db pools, each
> > having special characteristics and working best in different
> > situations ?
>
> Different, plug compatible, db pools would be great.
That's the key - "plug compatible". But we are in java, and writing a
simple adapter should be very easy. Adapters don't add so much complexity.
So the problem remains code organization - if the 2 DB pools would be
in the same repository ( with all other CPAN/CJAN modules ), projects
using DB pools may choose one - and if someone will have a different
opinion he can write a simple adapter, and make this configurable.
( in the end, either a merge or futher specialization will happen,
and very soon you'll have adapters to allow use of both )
Again, the key here is "same repository" - the modules should
shared and all commiters from all projects can grab, use or add ( without
project ownership - this module is part of tomcat or ant or whatever ).
> Having each project early bind to a specific one is not.
That's a problem with the _project_, not with the util.
It is normal to have afinities between projects - you can't get to CPAN if
you organize the code in projects.
> Overall, I'm not overly concerned if we have multiple XML mappers.
> Arguably it would be better if we didn't, but on the other hand a little
> duplication sometimes removes the requirement for a lot of coordination.
I mentioned the XML mapper because it's a particular piece of code I would
like to reuse, if it had fewer dependencies on the owning project ( right
now the deps are Project.log and properties that can easily be
abstracted).
I'm not very concerned about reusing the code ( we already have code for
reading the xml ), I'm concerned about using the same patterns.
BTW, ant is a perfect example for reuseing - there are many Tasks that
would be perfect CPAN modules ( i.e. can be used independently of ant).
Examples: javac ( in jasper ), expand ( in tomcat autodeploy ), dependency
checking ( tomcat reloading ). GTest ( the tester for tomcat ) started as
an ant task ( but using the proxy, i.e. it doesn't extends Task ).
IMHO ant is the closest thing to a CPAN that we have - there is minimal
dependency on the framework ( except extending Task - and that's the
biggest problem for me ). Most tasks are using only the logging facility
( easy to abstract by using a setLogger() and abstracting the log() out
of Task ). Except special tasks ( that set properties, etc ) there is no
other dependecy ( or didn't used to be - now there is a lot more )
--
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
