[Esapi-user] [Esapi-dev] What can I do next for ESAPI?

Kevin W. Wall kevin.w.wall at gmail.com
Sat Jul 31 17:12:02 EDT 2010

> There are a couple of outstanding things if I remember correctly.
> 1) breaking out ESAPI core and components into modules and/or separate
> jars.
> In my mind this is one of the most important things we need to work on for
> future versions. This has been a huge hurdle for a lot of the adopters
> that I have spoken to, the large number of dependencies introduces
> a pretty significant amount of risk into getting esapi into existing
> applications. People should be able to integrate the esapi in smaller
> pieces to minimize risk and scope of impact on their app.

True...that's probably (IMHO) *the* most important thing that needs work,
but it's also a major architectural change (e.g., using dependency injection,
and ideally separation of config files as well), so I think that's something
that we, as the ESAPI development needs to discuss a bit more before I or
anyone else simply dives into it headfirst. And even if we just all agree
that we will use DI (aka, IoC), then we need to decide if we are going to
use something like PicoContainer or Spring to implement DI or will we
write our own DI infrastructure. Lots of stuff to decide here before
any coding starts.

> 2) usable contrib components structure.
> Another important piece. A lot of people are already using libs for a
> lot of these concerns and it would make adoption a great deal easier if
> they could drop a contrib jar into the classpath, make some configuration
> changes and have a working component based on what they already have -
> for example Spring Security authentication and access control.
> I am sure there are more, but these are some of the larger more impactful
> changes that we have talked about.

Now that you mention it, I did think of maybe working on a contrib component
for Acegi Security for their LdapAuthenticationProvider. (Most people use
Acegi for Spring, right?) However, I thought it would make sense to do it
separate from Spring so that someone could use it if they were only using
Acegi and not using Spring. (I think I know a few cases at Qwest where that's

But, OTOH, it looks as though none of the contrib components even exist
yet. So before I start on anything like that, I would want to know how
we intend to deliver this contrib? Specifically, do we assume we need to
deliver any dependencies or can we just have a (separate?) pom.xml and have
Maven resolve / download all the dependency issues. This would be especially
relevant if something were done with Spring for example. Also, if there are
version dependencies, how do we want to handle that? I'm OK w/ just letting
Maven resolve everything, but there seems to be quite a few ESAPI users who
are not using Maven and just download the ESAPI .zip file. Also, would we
make a separate ESAPI-contrib.zip file or include it with ESAPI itself?

I almost think that if we don't address your issue #1 above, we are either
going to have to require people use Maven (or perhaps build an RPM or .de
file for Linux developers and a .msi for Windows users). So in that context,
#1 seems even more important.

Kevin W. Wall
"The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents."        -- Nathaniel Borenstein, co-creator of MIME

More information about the Esapi-user mailing list