Hi Ichiro, I did have a brief look at your code JSPWIKI-806. The xml configuration, the public, private, protected modifiers, etc. Will need to do a 3 way diff to continue with your work. But will look into this further.
Cheers, David V On 17/02/2015 12:23 PM, "Ichiro Furusato" <ichiro.furus...@gmail.com> wrote: > Hi, > Some months ago I was assigned lead on a large project that has all > but eliminated any time for other work, so apologies for my absence. > > I'd done a fair bit of work towards several new APIs in mind of some > of the cleanup work that Janne had indicated years ago, plus some > ideas of my own. I can't remember off the top of my head exactly how > far I'd got down that road, but I believe I may have sent the code > along to Juan Pablo, though I certainly don't hold him responsible > for remembering the details or holding a copy of the code. In looking > at JSPWIKI-806 some of this comes back to me... > > There are a number of significant issues with the current JSPWiki > API, and the EntityManager was an attempt to solve several at once: > the bootstrap code for the engine, i.e., how the various managers > were configured and instantiated, as well as how they were accessed. > This would have significant impact on things like the PluginManager, > SearchManager, and the like, and permit much easier reconfiguration > of the engine. Basically open it up completely during the bootstrap > process. > > The basic idea is that almost everything inside of JSPWiki becomes, > in addition to being a Java Object, also a declared "entity", registered > by ID in the EntityManager. All large Objects such as managers are > instantiated by the EntityManager, no longer by the WikiEngine. > > The bootstrapping process occurs in three phases, associated with > three levels of object read and write permissions: 1. private 2. protected; > and 3. public. This was to intended to be similar Unix/Linux permissions, > insofar as declaration and usage, so that it was easily understandable > both to the JSPWiki team developers and the developers using it. The > three phases are: 1. engine bootstrap; 2. creation of all configured > entities; then 3. "public" (open) access. So there's that necessary cross > of phase and permissions. The one obvious hole is that none of the > existing APIs have any concept of "read-only" and "modify" aspects to > their various methods. So maybe that's overkill. > > Any entity declared private can be instantiated by the EntityManager > only during WikiEngine bootstrapping, i.e., once that has occurred > any subsequent attempt at instantiatiation of a private object throws > an exception. Following bootstrap (once the engine is running) any > entities declared protected can still be instantiated by anything > within the wiki, but not by user-level code such as plugins. Finally, > user-level code such as plugins or page-level scripts can instantiate > public entities. Entity names are required to be XML IDs (to permit > both configuration and serialization), and there is no overwrite (as > in XML, first-declared stands)Entity names are required to be XML IDs > (to permit both configuration and serialization), and there is no > overwrite (as in XML, the first-declared entity stands). > > There was to be both read and write permissions, so that certain internal > entities (such as the security manager) could be declared read-private or > read-protected and therefore not be accessable outside the WikiEngine. I > thought about assigning rights to each entity based on some kind of role > assignment but that seemed overly complicated, and as the goal of this > exercise was to simplify the API this seemed counterproductive. The whole > question of how complicated to make the security aspect of the design I > hadn't really dealt with, as I wasn't dealing with real use cases (or > corresponding with any of the security people on the team). > > The configuration files were XML and meant to cascade, in that we'd > still permit an XML equivalent of the administrator's jspwiki.properties > file to override the native configuration. > > I don't believe I got that far in implementation, in particular I don't > remember doing anything about the permission set, but I can dig around > and find that code if anyone is interested. There'd probably be at least > the EntityManager and the beginnings of rewriting the WikiEngine bootstrap > according to it. I do remember that rewriting the bootstrapping was a pain, > but I think I'd got it working, dunno. > > I'd originally hoped to actually write the entirety of the API and code > changes on my own, but time as always is short and I didn't finish before > I got pulled off to other things. > > Cheers, > > Ichiro > > > On Sat, Feb 14, 2015 at 12:45 AM, Juan Pablo Santos RodrÃguez < > juanpablo.san...@gmail.com> wrote: > > > Hi, > > > > I think the original is in here > > http://www.ecyrd.com/JSPWiki/wiki/JSPWiki3APIDesignProposal > > > > When JSPWiki first entered Apache incubator, one of the goals was to > have a > > stable API developers could code against, to ease the development of > common > > extensions (plugins, filters, etc). The related code went into [#1]. > > > > Later on, a second attempt to graduate from incubator was made, less > > ambitious w.r.t. code (3.0 targetted the API, a new JCR backend, stripes > > instead os JSPs, etc.). Later on, I did try to bring back the api > package, > > but so far is incomplete: I had in mind leaving [#2] without red squares, > > so we could be able to split the main jar into several smaller modules > > (i.e.: jspwiki-plugins, jspwiki-filters, etc.) The api package should > then > > arise by itself, but right now there is a cycle in that package, so it > > smells like there is something in there which needs to be rethinked. > > > > Also related to this, JSPWIKI-806 [#3] aimed to simplify the WikiEngine, > by > > introducing an EntityManager, but the code in there needs to be > completed. > > > > Finally, as most probably finishing this means breaking backwards > > compatibility, we should change to 2.11 when this is undertaken. > > > > > > hth, > > juan pablo > > > > > > [#1]: http://svn.apache.org/viewvc/jspwiki/branches/JSPWIKI_3_0_BRANCH/ > > [#2]: > > > > > https://analysis.apache.org/plugins/resource/139725?page=org.sonar.plugins.design.ui.page.DesignPage > > [#3]: https://issues.apache.org/jira/browse/JSPWIKI-806 > > > > > > > > > > > > On Thu, Feb 12, 2015 at 3:32 PM, Harry Metske <harry.met...@gmail.com> > > wrote: > > > > > I dont have it. I think it was originally from Janne and/or Andrew. > > > > > > Grtz. > > > Harry > > > Op 12 feb. 2015 09:35 schreef "David Vittor" <dvit...@gmail.com>: > > > > > > > Does anyone have the documentation that was originally here: > > > > http://www.jspwiki.org/wiki/JSPWiki3APIDesignProposal > > > > > > > > This is referenced from issue JSPWIKI-303. > > > > > > > > I think the work was pretty massive, but I'd like to see the design > to > > > see > > > > if it can be done in stages. Does anyone still have it? > > > > > > > > Cheers, > > > > David V > > > > > > > > > >
