This email relates to Jira WSS-45
(http://issues.apache.org/jira/browse/WSS-45).  I'd like to suggest that
this proposal should also resolve
http://issues.apache.org/jira/browse/WSS-23 and
http://issues.apache.org/jira/browse/WSS-37.

To summarize the role of the CryptoFactory type, in WSS4j (as I
understand it), the factory class allows applications to dynamically
load Crypto instances through one of its getInstance() operations.  Some
of these (overloaded) operations take an optional java.util.Properties
object, which the factory class passes directly to the Crypto instance
constructor.

However, java.util.Properties objects suffer from the fact that, as
Maps, they range only over strings; applications that may otherwise have
in-memory data (such as a previously-loaded or constructed Keystore),
pointers to parent objects, etc, have no opportunity to pass this
information to the loaded Crypto instance.  (Except perhaps by
downcasting the Crypto instance, and calling specialized mutators, but
it should be obvious that this would be unacceptable.)

The drawback to this proposal is that it results in an interface change
to a fairly common part of the API.  It's likely that many applications
use the CryptoFactory instance.  However, simple clients of the
CryptoFactory type should be unaffected -- the java.util.Properties type
implements java.util.Map, so the change is compatible for anyone who
currently passes a Properties instance.  The problem is for Crytpo
implementors (e.g., Merlin); these implementation classes will need to
be retooled to take a Map in their constructors, instead of a Properties
object.

A patch has been submitted under WSS-45.  This patch also includes a
mild refactor of the AbstractCrypto type, adding a new base type (which
AbstractCrypto extends).  This new base type allows applications to
exploit common functionality in a Crypto implementation, without having
to rely on the keystore loading features in the AbstractCrypto
implementation.

I look forward to discussion on this proposal.

-Fred


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

Reply via email to