Murray Altheim schrieb: > If you're doing a major overhaul of JSPWiki's authentication and authori- > zation it would seem that taking the existing AuthenticationManager and > AuthorizationManager classes as starting points and rewriting them (not > extending the existing) as necessary would be the way forward. Then, > using the existing feature of the ClassUtil (without modification), you > add your class mappings to ClassUtil's classmappings.xml file: > > public static final String MAPPINGS = "/ini/classmappings.xml"; > > then let WikiEngine instantiate them using the existing code: > > m_authenticationManager = (AuthenticationManager) > > ClassUtil.getMappedObject(AuthenticationManager.class.getName()); > m_authorizationManager = (AuthorizationManager) > ClassUtil.getMappedObject( > AuthorizationManager.class.getName()); > > I don't see how a modification of ClassUtil is necessary here. The real > grunt work is rewriting the two AA classes. But so far as I understand > your requirements, the existing machinery permits this.
As you show above, the WikiEngine class explicitly casts the returned object to class AuthenticationManager. So I must *subclass* AuthenticationManager or this code will throw a ClassCastException at runtime. But I cannot subclass AuthenticationManager because it is final, and so are many of its important methods. > You might investigate > the cascading property feature as well as ClassUtil.MAPPINGS if you > haven't > already. > >> BTW, it's not final methods in ClassUtil that are the problem, but final >> methods in AuthorizationManager and AuthenticationManager. > > Yes, but you probably just need to rewrite those classes anyway since > you're not using the same AA model. Perhaps I'm not understanding where > the problem really is, i.e., it would seem to be a case of rewriting > those two classes and setting the mappings so that ClassUtil instantiates > your rewritten classes rather than the existing two. The subclasses I have created do replace 90% of the functionality of the originals. However due to the class casting done in WikiEngine, they still need to subclass the originals - and final forbids that. The alternative, as mentioned, is to declare my new classes with the same package and classname as the originals, and place them earlier in the classpath so they completely hide (and replace) the originals. But that is not very elegant. And it may cause LGPL problems too; I'd rather not do that. Or an interface could be created based on the API for the existing AuthenticationManager, and the jspwiki code changed to access it only via that interface - and in particular, the WikiEngine changed to cast the returned object to the new interface, not the concrete final type. Then my new class could implement that interface and the original default implementation could remain final. But that is a pretty large patch.. Regards, Simon
