"FredrikJ" wrote : | 1. Wouldn't this be considered a major api change(?) and as such should not go in between two cr releases? | Unfortunately we ran into unexpected implementation problems that the current API could not address. We had to choose between complicating the system by introducing a secondary API, or breaking API compatibility and fixing the extensibility problems that lead to this issue in the first place. We decided that overall it was better to get a solid, extensible, and easy to use API with well defined behavior in the GA. Had this issue been discovered after GA, we would have not taken this option. Before making this change, we also posted a detailed proposal and asked for feedback from everyone. anonymous wrote : | 2. I understand that the benefit is that you can choose to declare only those listener methods you are interested of, thus reducing the amount of empty boilerplate listener methods. However, the downpart is that we are losing type safety here and I personally do not consider this a good bargain. | That is one of the benefits, although the main reason is to allow easy extensibility. In this model we can add a new notification type in a future release, and it will not break existing listeners. anonymous wrote : | Now, isn't this exactly why we have interfaces? An interface enforces signature and types. If we fail to honor the interface we get a nice compilation error, with the annotation based model we will get runtime checking and runtime errors. | As mentioned above, the interface in this particular use case is not the best fit. It can't be extended, and it forces you to choose between implementing a bunch of methods you don't care about, or polluting your inheritance tree with a JBoss Cache class. The annotation model lets you choose whatever class design fits your application the best. You do lose compile time checking, although the API is very simple and predictable. The run-time error occurs the first time you register a listener, which should be close to immediate. Also, I should note that this is not a unique concept. EJB3 and DI frameworks use similar concepts. anonymous wrote : | If we look at the list of available annotations here http://labs.jboss.com/file-access/default/members/jbosscache/freezone/doc... we can see that the input ot the methods differ. Now I have to switch between my IDE and the documentation to lookup the annotation and what the proper signature is. Should I fail to comply, my IDE will not tell me since there is no compile-time checking. | If you point your IDE to the JBossCache javadocs, you will be able to pull up the info without leaving it, since we put docs on all the annotations. Also there is an easy convention, all notification methods take a single parameter, and its type is the annotation name + "Event". i.e. @NodeModified public void doSomething(NodeModifiedEvent event) {} anonymous wrote : | Furthermore, since there is no longer a CacheListener interface, I cannot use that interface for listener-registration in layers created on top of the cache, forcing me either into allowing Object or creating my own Listener interface which will allow me at least some typesafety. But in the end I will never really know until the cache is started and every possible listener has been registered to the cache, right? | Yes, although typically this occurs right away. Also usually one would test their listener before going into production, as compile time safety does not promise run-time correctness. anonymous wrote : | Generally I'm not opposed annotations. I think they do fill a purpose, but I can't seem understand the reasons for this particular design decision. I appreciate your feedback, and I understand your concerns. We are still open to any ideas you have that can make this better. Here is the trail for all the design discussions that lead to these changes: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=110525 http://www.jboss.com/index.html?module=bb&op=viewtopic&t=111094 http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCacheListenerAPIProposal http://www.jboss.com/index.html?module=bb&op=viewtopic&t=110911 -Jason View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4064559#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...