I am a strong supporter of extracting an interface, even if a marker one.
Using string properties leads us to String oriented programming such as the
enableFeature in the previous example.
Compare string based programming:
Client.enableFeature(aString)
Versus type based:
Client.enable(feature)
I personally hate string based programming.
Regards
Guilherme Silveira
2011. 6. 24. ¿ÀÀü 11:43¿¡ "Bill Burke" <bburke_at_redhat.com>´ÔÀÌ ÀÛ¼º:
On 6/24/11 10:33 AM, Marek Potociar wrote:
I wonder if the same functionality is not already cove...
Yes, a user could do all these things, but then the user would have to know
the implementation detail of each feature. Some features may have more than
one filter (i.e. caching).
Think about if you were a caching provider for a JAX-RS client solution. In
my proposal you would:
1. Write a Feature @Provider
@Provider
public class JBossJaxrsCache implements Feature {...}
2. Register the Feature with the JAX-RS Client runtime. (Features could
also be registered automatically by the JAX-RS implementation by some
scanning or other mechanism)
3. User creates Client and enables feature
Client client = ...
client.enableFeature("jboss.**caching");
4. The JBossJAXRSCache Feature is listening for "enableFeaature" events. It
sees this event so it initializes a set of filters and registers them with
the client.
I'm just proposing a way to package up features.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com