[
https://issues.apache.org/jira/browse/JSPWIKI-806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan Pablo Santos RodrÃguez resolved JSPWIKI-806.
-------------------------------------------------
Fix Version/s: 2.11.0-M7
Resolution: Fixed
Done on 2.11.0-M7-git-16, the refactor at JSPWIKI-120 allowed to register
custom managers on the {{WikiEngine}} pretty easily:
* {{WikiEngine}} will look on classpath for an {{ini/classmappings-extra.xml}}
file, which has the same structure as the {{ini/classmappings.xml}} file
* If the {{ini/classmappings-extra.xml}} file is found, the {{Engine}} will
register each {{requestedClass}} with its correspondent {{mappedClass}}, and
thus making it accesible through the {{Engine#getManager( Class<?> )}} method
* The custom manager *must* have a no-arg constructor
* If there's a need to perform some initialization tasks involving the
{{Engine}}, the custom manager should implement
{{o.a.w.api.engine.Initializable}} and perform those tasks there
* The classes don't get registered in any particular order, as we're iterating
the contents of a {{Map}}
* As with "official" managers, if there are two {{requestedClass}} entries with
the same {{mappedClass}}, the last getting registered overwrites the other(s)
* Access to the entity is controlled through its access modifiers (the
{{Engine}} must be able to "see" it, though)
As the goal of this issue was to register custom managers, I'm setting it as
Resolved, please reopen if anything else is needed.
> EntityManager Proposal
> ----------------------
>
> Key: JSPWIKI-806
> URL: https://issues.apache.org/jira/browse/JSPWIKI-806
> Project: JSPWiki
> Issue Type: Improvement
> Components: Core & storage
> Reporter: Juan Pablo Santos RodrÃguez
> Priority: Major
> Fix For: 2.11.0-M7
>
> Attachments: jspwiki-war-newApi-20131211.tar.gz
>
>
> Taken from http://s.apache.org/wS:
> {quote}
> \[...]
> 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.
> \[...]
> {quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
