JSPWiki 3 API

[David Vittor <dv...@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

Re: JSPWiki 3 API

[David Vittor <dv...@gmail.com>]

Thanks for this Juan.

I can see from the below code Interfaces what this was trying to achieve.
It's a good idea, although ambitious.
http://svn.apache.org/viewvc/jspwiki/branches/JSPWIKI_3_0_BRANCH/src/java/org/apache/wiki/api/

I do like the idea of an EntityManager [#3], but we'd need to decide which
one to use.
1. Felix iPOJO =
http://felix.apache.org/documentation/subprojects/apache-felix-ipojo.html
(OSGI)
2. PicoContainer = http://picocontainer.codehaus.org - simple to use, but
getting old
3. Tapestry IoC = http://tapestry.apache.org/ioc.html  - might be too tied
to Tapestry?
4. Spring Beans =
http://www.tutorialspoint.com/spring/spring_architecture.htm - popular, and
large support base (a little large)
5. EntityManager => build our own
6. Others = http://java-source.net/open-source/containers (use an existing
one)

Cheers,
David V



On Fri, Feb 13, 2015 at 10:45 PM, Juan Pablo Santos Rodríguez <
juanpablo.santos@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 <ha...@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" <dv...@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
> > >
> >
>

Re: JSPWiki 3 API

[David Vittor <dv...@gmail.com>]

Hi Ichiro,

I did have a brief look at your code JSPWIKI-806. The xml configuration,
the public, private, protected modifiers, etc. Will need to do a 3 way diff
to continue with your work. But will look into this further.

Cheers,
David V
On 17/02/2015 12:23 PM, "Ichiro Furusato" <ic...@gmail.com> wrote:

> 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.santos@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 <ha...@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" <dv...@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
> > > >
> > >
> >
>

Re: JSPWiki 3 API

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

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.santos@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 <ha...@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" <dv...@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
> > >
> >
>

Re: JSPWiki 3 API

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

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 <ha...@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" <dv...@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
> >
>

Re: JSPWiki 3 API

[Harry Metske <ha...@gmail.com>]

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" <dv...@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
>