Hi Juan Pablo, I'm making good progress and have done about five of the interfaces so far of the ten managers I've got to so far. It's not taking me that long really to do a concrete class to interface conversion, and I'm a bit curious to know if people think doing *all* of the managers as interfaces makes sense or whether some are better left as concrete classes. The security managers (AuthenticationManager and AuthorizationManager) come to mind. Some managers are very unlikely to be extended, others more so.
I posted a "progress report" on a different thread, thought I better re-post it here: <summary> As a progress report, I've so far begun to gradually replace some of the managers with interfaces, built the EntityManager that acts like a bootstrap loader and creates all of the managers from an XML configuration file, then provides Map-style access to them (so that all of the getter methods in WikiEngine could be removed). Instantiation of managers is now happening within the EntityManager rather than within the WikiEngine. I've managed to do the first five managers (in instantiation order), but I'm noting that the order in which things are instantiated and initialised is in the future going to get a bit tricky, so if everything fails my fallback is to let the WikiEngine request the managers from the EntityManager using the existing instantiation/initialisation order via local variables, providing access only via the EntityManager once everything is up and running. </summary> Not the best summary but that's it so far. As I mentioned, the tricky part is the instantiation vs. initialisation ordering as found in WikiEngine. I'll hopefully come up with an elegant solution for that, dunno. Ichiro On Fri, Jul 12, 2013 at 9:34 AM, Juan Pablo Santos Rodríguez < [email protected]> wrote: > Hi Ichiro, > > nothing really disruptive, but I'd like to make the following changes: > > - WikiEngine returning interfaces instead of concrete Managers. May rename > concrete maangers along the way, e.g.: PluginManager becoming > DefaultPluginManager implements PluginManager > - Delete org.apache.wiki.WikiException in favour of > org.apache.wiki.api.WikiException > - Creation of an API module to hold Manager interfaces, general exceptions > and WikiEngine + WikiContext, once they aren't coupled to concrete classes > - Most probably WikiEngine should be passed as an interface (WikiEngine > implements Engine?); same for WikiContext. This can/could/should be done as > EntityManager takes shape > > However I'm afraid I can't give you a timeline for these; I'll expect to > begin next week, creating an api module with a few classes, an utils > module, again with a few classes and a filter module, holding all > WikiFilters related stuff > > > br, > juan pablo > > On Thu, Jul 11, 2013 at 11:35 AM, Ichiro Furusato < > [email protected] > > wrote: > > > Hi, > > > > I just have one further question prior to diving into this: is anyone > > out there actually modifying or substituting any of JSPWiki's > > primary managers? If so, I'd like to hear about it (offlist if you > > wish) so that I can be sure that what I'm doing is compatible with > > what you're doing (if it's not too outlandish). > > > > As was suggested, I've read over JSPWIKI-155 and I think the > > solution I've proposed will probably work in at least the 80/20 > > case, just not sure about the 90/10 until I hear from someone out > > on that limb. > > > > If I don't hear from anyone I'll assume that so long as the result is > > internally consistent I'll have some freedom to tear the living sh*t > > out of the insides of WikiEngine. At this point this whole thing is > > somewhat of an experiment anyway, but it might pan out. > > > > Ichiro > > > > > > On Thu, Jul 11, 2013 at 1:23 AM, Ichiro Furusato > > <[email protected]>wrote: > > > > > > > > > > > > > > On Wed, Jul 10, 2013 at 9:51 AM, Juan Pablo Santos Rodríguez < > > > [email protected]> wrote: > > > > > >> Hi Ichiro, > > >> > > >> I'm definitely interested, and will be glad to help with whatever I > can > > >> > > > > > > Hi Juan Pablo, > > > > > > That'd be great, thanks! > > > > > > > > >> One of the ideas behind JSPWIKI-155 is doing more or less the same > > thing, > > >> but without a separate class, i.e.: regarding the EntityManager, why > not > > >> moving it into WikiEngine (thinking in WikiEngine as an already > > ubiquitous > > >> class that will be returning interfaces and thus not carrying the > whole > > >> application from one manager to another)? > > >> > > > > > > I haven't looked over the existing proposals, will take a look at > > > JSPWIKI-155. > > > > > > I'll have to look into what benefits there might be in having the > > > EntityManager > > > either in or out of WikiEngine. I was thinking it might be the *only* > > > getter > > > method from WikiEngine (apart from the deprecated get*Manager() > methods). > > > > > > > > >> I specially like the idea of getting a (maybe new) manager from > > WikiEngine > > >> without declaring an specific method for it, it's very interesting, > and > > >> the > > >> idea of processing the Managers from a configuration file rather than > > >> explicitly instantiating (through ClassUtil.getMappedObject, but doing > > >> that > > >> explicitly) them. > > >> > > > > > > I've done something similar to this in a recent project and it just > seems > > > like > > > something that might have other possible uses (e.g., as a general > purpose > > > name-value pair storage). This raises the idea of having a parameter > > option > > > to permit some entities to be persisted across sessions, or used across > > > instances, things like that. > > > > > > > > >> Finally, a couple of notes/questions regarding the EntityManager > > >> - could classmappings.xml be the config file for the EntityManager > > >> (whether > > >> it becomes a new class or just a refactored WikiEngine)? We could add > > >> parameters as needed > > >> > > > > > > We could, but my only concern is that we'd then be overloading the > > > use of classmappings.xml, especially given their purposes are > different. > > > I'd really advocate a new XML file with a new syntax. Then there'd be > > > no potential for pollution. > > > > > > > > >> - I would "include" a mandatory field for each Manager. If it's > > mandatory, > > >> the WikiEngine cannot initialize, and the application doesn't start. > If > > it > > >> isn't, the error is simply logged. > > > > > > > > > Hmm. Under what circumstances would the EntityManager permit a > > > failure? I'd think all of them would be mandatory. One thing I had > > thought > > > of might be permitting (via parameter) lazy instantiation though. Not > > > everything needs to be there right at the beginning -- the > EntityManager > > > could create managers only when needed then, i.e., upon first request. > > > > > > Cheers, > > > > > > Ichiro > > > > > > rgrds, > > >> juan pablo > > >> > > >> On Tue, Jul 9, 2013 at 10:52 AM, 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 > > >> > > > >> > > > > > > > > >
