incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ichiro Furusato <>
Subject Re: EntityManager proposal
Date Wed, 10 Jul 2013 13:23:59 GMT
On Wed, Jul 10, 2013 at 9:51 AM, Juan Pablo Santos Rodríguez <> 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

I'll have to look into what benefits there might be in having the
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
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.



> juan pablo
> On Tue, Jul 9, 2013 at 10:52 AM, Ichiro Furusato
> <>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* 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
> >

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