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

Kevin W. Wall kevin.w.wall at gmail.com
Sun Aug 8 21:49:40 EDT 2010

Jim Manico wrote:

> I think modularization and documentation are the 2 most important issues to
address after ESAPI 2.0 is a production release.
> Perhaps we could start simple - like just splitting the core and the reference
> implementation? That's tricky enough.
> Why do we need DI? Do we need a major re-write?

Chris and I think that using DI is probably the most *straightforward* way to
solve the dependency problem of the score of external jar files that
the reference implementation is dependent upon. (See the jar dependencies
under target/site/dependencies.html after executing 'mvn site'. Looks like
there are 33 jars that ESAPI is dependent on.)

Certainly if we can split out the major pieces of ESAPI in major
features -- e.g., along the major interfaces, then DI can be used
to address the dependency cycles that we have at runtime.

> I'd love to eventually remove •all• dependencies. :) It's pretty out
> of control right now. Perhaps we could get more visibility into
> this topic as part of the componentization push for 3.0? 

This definitely is not something we put into 2.0, but are we planning
on a 2.1 release? If so, will that just be bug fixes? If 2.1 is just
bug fixes, then 3.0 is where it should go. But they way it is today
seriously is an impediment to it's adoption IMO. I think there needs
to be some general release planning done.

> I think that once we start splitting ESAPI into different pieces
>it will be a lot easier to analyze dependencies and see which easy
> ones, at least, we can drop.

The Jdepend output under target/site/jdepend-report.html is a good
start at this. I don't think it would be too hard to come up with
a reasonable division of ESAPI jars (e.g., esapi-core, esapi-encoder,
esapi-crypto, etc.). If you want to build from scratch, you still need
all, but we split up the distribution so that if all you want is the
ESAPI crypto, you only need (omitting appropriate version numbering for
clarity) esapi-core.jar, esapi-crypto.jar, and log4j.jar. (That would assume
that some of the general codecs should be moved into the esapi-core, such
as the one for base64 and hex encoding. Ditto with all the ESAPI interfaces
and the org.owasp.esapi.errors and org.owasp.esapi.util packages.)

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