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 > > > > > >
