Actually, kinda both. I'll zip up everything I've got then and either attach it to JSPWIKI-155 (if I can manage to log in), post it and provide a URL or send it to you directly. I'll hopefully find time tonight.
Cheers, Ichiro On Mon, Dec 9, 2013 at 9:03 PM, Juan Pablo Santos Rodríguez < juanpablo.san...@gmail.com> wrote: > Hi Ichiro, > > the EntityManager or the interface extraction? In any case, yes please, > would you mind uploading it as an attachment to JSPWIKI-155? > > thanks! > > > br, > juan pablo > > > On Mon, Dec 9, 2013 at 2:28 AM, Ichiro Furusato > <ichiro.furus...@gmail.com>wrote: > > > Hi Juan Pablo, > > > > Since I've kinda already done most of this would you like me to send you > > what I've got? > > It might be a good starting point and I wouldn't feel like I've wasted > that > > effort... > > > > Ichiro > > > > > > On Thu, Dec 5, 2013 at 11:49 AM, Juan Pablo Santos Rodríguez (JIRA) < > > j...@apache.org> wrote: > > > > > > > > [ > > > > > > https://issues.apache.org/jira/browse/JSPWIKI-155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13839435#comment-13839435 > > ] > > > > > > Juan Pablo Santos Rodríguez commented on JSPWIKI-155: > > > ----------------------------------------------------- > > > > > > All managers are currently injected via ClassUtil.getMappedObject. As a > > > last step before marking as resolved this issue, interfaces should be > > > extracted from managers; this will be done following some rules of > thumb: > > > - interfaces should be part of o.a.w.api.engine package > > > - initially, they should publish all public operations from the given > > > manager (later on, at JSPWIKI-303 timeframe, we'll most probably > refactor > > > these operations) > > > - the interface will be named as the Manager and the Manager will be > > > prefixed with Default (i.e. -> o.a.w.plugin.PluginManager will get > > splitted > > > into o.a.w.api.engine.PluginManager (interface) and > > > o.a.w.plugin.DefaultPluginManager (class)). > > > - use of the new interface over the concrete manager throughout the > code > > > - concrete Managers should not be final, to allow inheritance > > > > > > thoughts/alternatives? > > > > > > > Allow customisation of core classes via ClassUtil.getMappedObject > > > > ----------------------------------------------------------------- > > > > > > > > Key: JSPWIKI-155 > > > > URL: > https://issues.apache.org/jira/browse/JSPWIKI-155 > > > > Project: JSPWiki > > > > Issue Type: Improvement > > > > Components: Core & storage > > > > Affects Versions: 2.6.0 > > > > Reporter: Simon Kitching > > > > Priority: Minor > > > > Fix For: 2.10 > > > > > > > > > > > > The WikiEngine class uses the ClassUtils.getMappedObject method to > > > locate its critical helper objects, rather than just call "new". > > > > The intentention of this existing code is for people to be able to > > > override the core implementations with custom ones - with the warning > > that > > > these core objects do not have stable public apis, and may change in > any > > > release. Unfortunately because (a) the returned object is cast to a > > > concrete type, and (b) many of these concrete types are declared > "final" > > > this facility is actually almost useless. > > > > It would be nice for the "final" to be removed from these classes, > and > > > from their member methods so that getMappedObject becomes useful. > > > Alternately, interfaces could be created for the concrete classes that > > > WikiEngine currently uses, and all code modified to use the interface > > > instead; the existing implementations could then remain final. That > > > approach is much more intrusive though. > > > > Note that in discussions on the email lists it has been suggested > that > > > the "final" qualifier on these classes helps make jspwiki more secure. > > > Personally I'm not at all convinced that is true though. > > > > > > > > > > > > -- > > > This message was sent by Atlassian JIRA > > > (v6.1#6144) > > > > > >
