Hi Ichiro, I'm +1 with Glen, https://issues.apache.org/jira/browse/JSPWIKI-155 or https://issues.apache.org/jira/browse/JSPWIKI-303 might be good candidates to attach the tar/patch to
thx for your time on looking into this + br, juan pablo On Thu, Sep 5, 2013 at 3:22 AM, Glen Mazza <[email protected]> wrote: > Hi Ichiro, yes, please keep your work, someone may wish to look at it in > the future. (Perhaps you can enter it as a JIRA as an enhancement request > and supply a patch giving a general idea of what you're thinking about.) > My time is now also constrained due to other needs and it may be awhile > before I can do much for JSPWiki. (Also, Harry, I'm not sure when I can > look at the ehcache stuff, I would go ahead with it if it seems good to > you.) > > Regards, > Glen > > > On 09/04/2013 07:44 AM, Ichiro Furusato wrote: > >> Hi, >> >> I've recently found that the window I thought I had to do some extra work >> has disappeared, >> such that the EntityManager work has been put on hold indefinitely. I'd >> hoped Murray might >> be able to pick some of this up but he's tied up as well. >> >> I had got to the point where I'd modified WikiEngine to instantiate most >> of >> the managers >> from the EntityManager following a bootstrap load of them via a config >> file. The WikiEngine >> then simply grabs them from the EntityManager. The idea was to gradually >> remove >> unnecessary references in WikiEngine and force the rest of the application >> to obtain the >> managers from the EntityManager's map via their string identifiers, with >> restrictions on that >> access set via the EntityManager's config. >> >> I'd ideally like to finish this but I simply don't know when I'll have >> time >> -- it's not looking I will >> prior to Christmas at this point. My apologies for not being able to >> deliver this work -- I >> believe it represents a simpler and cleaner way to start up the >> application. As JSPWiki has >> gotten more complicated over the years it's just seemed to burden the >> engine with too much >> baggage. An EntityManager (or "ManagerManager") seems like an appropriate >> solution. >> >> If anyone is interested in this work I'm happy to post a tarball and >> provide its location. >> >> Cheers, >> >> Ichiro >> >> >> On Tue, Jul 9, 2013 at 8:52 PM, Ichiro Furusato >> <[email protected]>**wrote: >> >> Hi, >>> >>> I'm in the middle of working through some new manager classes as a >>> supplement to JSPWiki. These managers will be singletons similar to >>> the dozen or so existing managers that get instantiated in the method >>> WikiEngine.initialize(), such as the PageManager, PluginManager, etc. >>> >>> The following is *not* a commitment to work, it is an offer to share the >>> results if I'm able to (a) find the time to finish it; and (b) I can make >>> it >>> work; and (c) people are interested. I'm seeking feedback about the >>> proposed design. I'm not currently a team member but I could pass the >>> code or patches on to someone to check in if necessary. >>> >>> What I'm considering is potentially a solution to the note in that method >>> concerning the "unwieldy" nature of the current approach of building the >>> WikiEngine's managers, namely a new EntityManager that would >>> sequentially create all the current managers according to a configuration >>> file, such that each manager (entity) could then be referred to by name. >>> This would also permit additional entities (like my new manager) to be >>> added and subsequently referred to by name. >>> >>> The only thing one would need to gain access to the EntityManager would >>> be the WikiEngine itself -- all other managers would therefore be >>> available >>> by name and all of the existing getter methods could be deprecated and >>> eventually the WikiEngine would therefore be simplified. The WikiEngine >>> would spawn a singleton EntityManager and then let it handle access to >>> those entities. >>> >>> The configuration for the EntityManager would be an XML file, where >>> each individual entity configuration would include the following >>> parameters: >>> >>> * identifier (package name) of the entity >>> >>> * boot order parameter (1-n) OR order in file is used. >>> >>> * boolean stating whether the entity can be modified/replaced >>> once created >>> >>> * access modifiers suggesting permitted access to the entity: >>> 'private' : only to the WikiEngine itself >>> 'protected' : only to org.apache.wiki.* code >>> 'public' : open access >>> [not sure how to do this but could get some advice from one of >>> the team's security experts] >>> >>> * anything else? >>> >>> This would obviously involve a substantial rewiring of the engine and >>> current managers, as they tend to gain access to each other via the >>> WikiEngine, hence the idea of deprecating the existing methods in >>> WikiEngine (and implementing their current getters via the EntityManager) >>> rather than eliminating them outright. Once done though, this would >>> greatly simplify the WikiEngine itself. It basically would have a new >>> bootstrap manager. >>> >>> To give you an idea of what problem I'm trying to solve, we're currently >>> developing an updated TagManager based on Murray Altheim's existing >>> TagPlugin (and related features) to provide a tagging solution for >>> JSPWiki, as well as a GroovyService to provide a wiki-related Groovy >>> scripting solution, supporting an update to our older GroovyPlugin but >>> also permitting a wiki page-based command console (obviously not for >>> use on public wikis). You'd have a on-page form as a console drawing >>> upon a 'bin' directory of Groovy scripts, basically a file-based DSL over >>> Groovy command line functionality. So you could write a HelloWorld.grv >>> file, put it in the WEB-INF/bin directory and be able to type >>> 'HelloWorld' >>> into the console command line. That kind of thing. We have this mostly >>> working already so this is basically a way to add a new manager >>> without either adding a getter to the WikiEngine or gaining access via >>> some singleton trickery. >>> >>> If this sounds palatable to the group I'll go ahead and begin coding in >>> mind of it being a public effort (with appropriate Apache license headers >>> in the files, etc.), otherwise I'll build it as an addon for our own >>> local >>> use. >>> >>> I would like to know one question if I do begin: should I simply work on >>> the trunk or would this be better as a branch? If so I'd need someone to >>> create that branch. >>> >>> If I end up running out of steam I might want some help, particularly on >>> the security-related stuff since that's not my forte. If anyone is up for >>> helping in this regard please let me know. >>> >>> Cheers, >>> >>> Ichiro >>> >>> >>> >>> >
