jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Juan Pablo Santos Rodríguez <juanpablo.san...@gmail.com>
Subject Re: [jira] [Commented] (JSPWIKI-155) Allow customisation of core classes via ClassUtil.getMappedObject
Date Mon, 09 Dec 2013 08:03:38 GMT
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.furusato@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) <
> jira@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)
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message