Re: EntityManager proposal

[Ichiro Furusato <ic...@gmail.com>]

Hi,

I've recently found that the window I thought I had to do some extra work
has disappeared,
such that the EntityManager work has been put on hold indefinitely. I'd
hoped Murray might
be able to pick some of this up but he's tied up as well.

I had got to the point where I'd modified WikiEngine to instantiate most of
the managers
from the EntityManager following a bootstrap load of them via a config
file. The WikiEngine
then simply grabs them from the EntityManager. The idea was to gradually
remove
unnecessary references in WikiEngine and force the rest of the application
to obtain the
managers from the EntityManager's map via their string identifiers, with
restrictions on that
access set via the EntityManager's config.

I'd ideally like to finish this but I simply don't know when I'll have time
-- it's not looking I will
prior to Christmas at this point. My apologies for not being able to
deliver this work -- I
believe it represents a simpler and cleaner way to start up the
application. As JSPWiki has
gotten more complicated over the years it's just seemed to burden the
engine with too much
baggage. An EntityManager (or "ManagerManager") seems like an appropriate
solution.

If anyone is interested in this work I'm happy to post a tarball and
provide its location.

Cheers,

Ichiro


On Tue, Jul 9, 2013 at 8:52 PM, Ichiro Furusato
<ic...@gmail.com>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
>
>
>

Re: EntityManager proposal

[Ichiro Furusato <ic...@gmail.com>]

Hi Juan Pablo,

Thanks for the references. In looking over the notes to JSPWIKI-155, in
particular, I believe the EntityManager approach provides a mitigating
solution to what is I agree a security hole big enough to drive a truck
through (notwithstanding that plugins can do anything anyway, but
users/installers have the choice of uninstalling plugins they don't want
present, whereas this is at the core of the application).

Given what I've accomplished so far is to refactor a lot of the managers as
implementations of new interfaces and instantiating them via the
EntityManager, it might be possible for someone to without *too* much
effort incorporate the code into the existing trunk; then anyone could
continue along that track in the future. I'll see if I can over the next
week do a cleanup and attach either a patch or a zip of the code to the
issue.

Ichiro


On Fri, Sep 6, 2013 at 6:09 AM, Juan Pablo Santos Rodríguez <
juanpablo.santos@gmail.com> wrote:

> Hi Ichiro,
>
> I'm +1 with Glen, https://issues.apache.org/jira/browse/JSPWIKI-155 or
> https://issues.apache.org/jira/browse/JSPWIKI-303 might be good candidates
> to attach the tar/patch to
>
>
> thx for your time on looking into this + br,
> juan pablo
>
>
>
> On Thu, Sep 5, 2013 at 3:22 AM, Glen Mazza <gl...@gmail.com> wrote:
>
> > Hi Ichiro, yes, please keep your work, someone may wish to look at it in
> > the future.  (Perhaps you can enter it as a JIRA as an enhancement
> request
> > and supply a patch giving a general idea of what you're thinking about.)
> >  My time is now also constrained due to other needs and it may be awhile
> > before I can do much for JSPWiki.  (Also, Harry, I'm not sure when I can
> > look at the ehcache stuff, I would go ahead with it if it seems good to
> > you.)
> >
> > Regards,
> > Glen
> >
> >
> > On 09/04/2013 07:44 AM, Ichiro Furusato wrote:
> >
> >> Hi,
> >>
> >> I've recently found that the window I thought I had to do some extra
> work
> >> has disappeared,
> >> such that the EntityManager work has been put on hold indefinitely. I'd
> >> hoped Murray might
> >> be able to pick some of this up but he's tied up as well.
> >>
> >> I had got to the point where I'd modified WikiEngine to instantiate most
> >> of
> >> the managers
> >> from the EntityManager following a bootstrap load of them via a config
> >> file. The WikiEngine
> >> then simply grabs them from the EntityManager. The idea was to gradually
> >> remove
> >> unnecessary references in WikiEngine and force the rest of the
> application
> >> to obtain the
> >> managers from the EntityManager's map via their string identifiers, with
> >> restrictions on that
> >> access set via the EntityManager's config.
> >>
> >> I'd ideally like to finish this but I simply don't know when I'll have
> >> time
> >> -- it's not looking I will
> >> prior to Christmas at this point. My apologies for not being able to
> >> deliver this work -- I
> >> believe it represents a simpler and cleaner way to start up the
> >> application. As JSPWiki has
> >> gotten more complicated over the years it's just seemed to burden the
> >> engine with too much
> >> baggage. An EntityManager (or "ManagerManager") seems like an
> appropriate
> >> solution.
> >>
> >> If anyone is interested in this work I'm happy to post a tarball and
> >> provide its location.
> >>
> >> Cheers,
> >>
> >> Ichiro
> >>
> >>
> >> On Tue, Jul 9, 2013 at 8:52 PM, Ichiro Furusato
> >> <ic...@gmail.com>**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
> >>>
> >>>
> >>>
> >>>
> >
>

Re: EntityManager proposal

[Juan Pablo Santos Rodríguez <ju...@gmail.com>]

Hi Ichiro,

I'm +1 with Glen, https://issues.apache.org/jira/browse/JSPWIKI-155 or
https://issues.apache.org/jira/browse/JSPWIKI-303 might be good candidates
to attach the tar/patch to


thx for your time on looking into this + br,
juan pablo



On Thu, Sep 5, 2013 at 3:22 AM, Glen Mazza <gl...@gmail.com> wrote:

> Hi Ichiro, yes, please keep your work, someone may wish to look at it in
> the future.  (Perhaps you can enter it as a JIRA as an enhancement request
> and supply a patch giving a general idea of what you're thinking about.)
>  My time is now also constrained due to other needs and it may be awhile
> before I can do much for JSPWiki.  (Also, Harry, I'm not sure when I can
> look at the ehcache stuff, I would go ahead with it if it seems good to
> you.)
>
> Regards,
> Glen
>
>
> On 09/04/2013 07:44 AM, Ichiro Furusato wrote:
>
>> Hi,
>>
>> I've recently found that the window I thought I had to do some extra work
>> has disappeared,
>> such that the EntityManager work has been put on hold indefinitely. I'd
>> hoped Murray might
>> be able to pick some of this up but he's tied up as well.
>>
>> I had got to the point where I'd modified WikiEngine to instantiate most
>> of
>> the managers
>> from the EntityManager following a bootstrap load of them via a config
>> file. The WikiEngine
>> then simply grabs them from the EntityManager. The idea was to gradually
>> remove
>> unnecessary references in WikiEngine and force the rest of the application
>> to obtain the
>> managers from the EntityManager's map via their string identifiers, with
>> restrictions on that
>> access set via the EntityManager's config.
>>
>> I'd ideally like to finish this but I simply don't know when I'll have
>> time
>> -- it's not looking I will
>> prior to Christmas at this point. My apologies for not being able to
>> deliver this work -- I
>> believe it represents a simpler and cleaner way to start up the
>> application. As JSPWiki has
>> gotten more complicated over the years it's just seemed to burden the
>> engine with too much
>> baggage. An EntityManager (or "ManagerManager") seems like an appropriate
>> solution.
>>
>> If anyone is interested in this work I'm happy to post a tarball and
>> provide its location.
>>
>> Cheers,
>>
>> Ichiro
>>
>>
>> On Tue, Jul 9, 2013 at 8:52 PM, Ichiro Furusato
>> <ic...@gmail.com>**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
>>>
>>>
>>>
>>>
>

Re: EntityManager proposal

[Glen Mazza <gl...@gmail.com>]

Hi Ichiro, yes, please keep your work, someone may wish to look at it in 
the future.  (Perhaps you can enter it as a JIRA as an enhancement 
request and supply a patch giving a general idea of what you're thinking 
about.)  My time is now also constrained due to other needs and it may 
be awhile before I can do much for JSPWiki.  (Also, Harry, I'm not sure 
when I can look at the ehcache stuff, I would go ahead with it if it 
seems good to you.)

Regards,
Glen

On 09/04/2013 07:44 AM, Ichiro Furusato wrote:
> Hi,
>
> I've recently found that the window I thought I had to do some extra work
> has disappeared,
> such that the EntityManager work has been put on hold indefinitely. I'd
> hoped Murray might
> be able to pick some of this up but he's tied up as well.
>
> I had got to the point where I'd modified WikiEngine to instantiate most of
> the managers
> from the EntityManager following a bootstrap load of them via a config
> file. The WikiEngine
> then simply grabs them from the EntityManager. The idea was to gradually
> remove
> unnecessary references in WikiEngine and force the rest of the application
> to obtain the
> managers from the EntityManager's map via their string identifiers, with
> restrictions on that
> access set via the EntityManager's config.
>
> I'd ideally like to finish this but I simply don't know when I'll have time
> -- it's not looking I will
> prior to Christmas at this point. My apologies for not being able to
> deliver this work -- I
> believe it represents a simpler and cleaner way to start up the
> application. As JSPWiki has
> gotten more complicated over the years it's just seemed to burden the
> engine with too much
> baggage. An EntityManager (or "ManagerManager") seems like an appropriate
> solution.
>
> If anyone is interested in this work I'm happy to post a tarball and
> provide its location.
>
> Cheers,
>
> Ichiro
>
>
> On Tue, Jul 9, 2013 at 8:52 PM, Ichiro Furusato
> <ic...@gmail.com>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
>>
>>
>>