James,
Given your proposal, how would a user or adopter/vendor configure a
custom cache coordination implementation? It would be nice if they
could register their implementation via a property in the
eclipselink.cache.coordination "namespace", something like
eclipselink.cache.coordination.type = example.MyCustomImpl. "Type" is
the name of the field in the Workbench's session editor where this can
be specified but I'm not sure this word is evocative as a property
name. Along with a custom coordination 'type' implementation a
collection of related properties such as
"eclipselink.cache.coordination.mucustomimpl.*" could be defined by the
implementation. As long as all properties are provided as the cache
coordination impl is created this would would work nicely.
This issue of extension/substitution is actually broader than just
cache coordination. There are other places where we have "out of the
box" implementations that can either be extended or replaced.
Providing a way to plug in alternate implementations of
strategies/class that are currently hardwired in EclipseLink has been
raise on the dev list before and a standard property based approach may
address this.
Shaun
James Sutherland wrote:
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
--
Shaun Smith | Principal Product Manager
Phone: +19055023094
Oracle Server Technologies, Oracle TopLink
ORACLE Canada | 110 Matheson Boulevard West, Suite 100, Mississauga,
Ontario | L5R 3P4
Oracle is committed to developing practices and products that
help protect the environment
|