You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jspwiki.apache.org by Murray Altheim <mu...@altheim.com> on 2008/06/24 13:29:07 UTC
Controllable API
Not that anyone is paying that close attention, but if you have
you'd note that I'm managing a LOT of plugins. They're growing
like fungus around here. Now, I'm not trying to offload them but
my time lately has been very tight and testing has been a pain
since my typical build installation includes all of them, such
that I'm never sure of interactions. Lately I've been getting
ping'd on a number of different plugin packages that have been
bundled in the large CeryleWiki plugins jar file. I should
probably break that thing into much smaller jars. Time willing...
It occurs to me to create a very simple "Controllable" API and
add a minor callout in the PluginManager to disable the function
of a plugin based on it occurring in an excluded list, or enable
it based on an included list (either? both?). A disabled plugin
would either be entirely ignored by the parser/PluginManager,
return an empty string, or some kind of error message (this might
be defined by the API). I'm thinking of writing some kind of UI
or JSP to permit an administrator to individually set a flag for
each plugin.
Any thoughts on this? Bad idea? Good idea? Not an interesting
idea? When might this might make sense, JSPWiki-version-wise?
Thanks,
Murray
...........................................................................
Murray Altheim <murray07 at altheim.com> === = =
http://www.altheim.com/murray/ = = ===
SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk = = = =
Boundless wind and moon - the eye within eyes,
Inexhaustible heaven and earth - the light beyond light,
The willow dark, the flower bright - ten thousand houses,
Knock at any door - there's one who will respond.
-- The Blue Cliff Record
Re: Controllable API
Posted by Fabian Haupt <ka...@submerged-intelligence.de>.
Although my opinion won't count very much, i'd regard that as a great
idea. This would make it possible to enable/disable plugins as needed
without the need for a restart of the whole container. This would pave
the way for the addition and removal of plugins completely at runtime,
not only to disable/enable them.
Greets,
Fabian
Murray Altheim schrieb:
> Not that anyone is paying that close attention, but if you have
> you'd note that I'm managing a LOT of plugins. They're growing
> like fungus around here. Now, I'm not trying to offload them but
> my time lately has been very tight and testing has been a pain
> since my typical build installation includes all of them, such
> that I'm never sure of interactions. Lately I've been getting
> ping'd on a number of different plugin packages that have been
> bundled in the large CeryleWiki plugins jar file. I should
> probably break that thing into much smaller jars. Time willing...
>
> It occurs to me to create a very simple "Controllable" API and
> add a minor callout in the PluginManager to disable the function
> of a plugin based on it occurring in an excluded list, or enable
> it based on an included list (either? both?). A disabled plugin
> would either be entirely ignored by the parser/PluginManager,
> return an empty string, or some kind of error message (this might
> be defined by the API). I'm thinking of writing some kind of UI
> or JSP to permit an administrator to individually set a flag for
> each plugin.
>
> Any thoughts on this? Bad idea? Good idea? Not an interesting
> idea? When might this might make sense, JSPWiki-version-wise?
>
> Thanks,
>
> Murray
>
> ...........................................................................
> Murray Altheim <murray07 at altheim.com> === = =
> http://www.altheim.com/murray/ = = ===
> SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk = = = =
>
> Boundless wind and moon - the eye within eyes,
> Inexhaustible heaven and earth - the light beyond light,
> The willow dark, the flower bright - ten thousand houses,
> Knock at any door - there's one who will respond.
> -- The Blue Cliff Record
Re: Controllable API
Posted by Murray Altheim <mu...@altheim.com>.
Janne Jalkanen wrote:
>> It occurs to me to create a very simple "Controllable" API and
>> add a minor callout in the PluginManager to disable the function
>> of a plugin based on it occurring in an excluded list, or enable
>> it based on an included list (either? both?). A disabled plugin
>> would either be entirely ignored by the parser/PluginManager,
>> return an empty string, or some kind of error message (this might
>> be defined by the API). I'm thinking of writing some kind of UI
>> or JSP to permit an administrator to individually set a flag for
>> each plugin.
>
> I was actually going to do something like that but sort of ran out of
> time. Admin.jsp allows you to list all the installed plugins, and the
> idea was that you could turn plugins (well, any kind of modules:
> filters, editors, etc) on and off from there.
>
> Essentially it would mean a new field in the WikiModuleInfo, and
> necessary code in the PluginManager. I would most prefer if the UI were
> in the form of an AdminBean.
This is where all of the new code complexity begins to show its downside.
How many new technologies would I have to learn to be able to write this
nowadays? I must admit I've not spent much time dealing with beans at all,
and certainly haven't looked into the com.ecyrd.jspwiki.ui.admin.*
package in any detail, nor the WikiInfoModule, nor Struts, nor JMX. So I
can understand why you might have ran out of time. I'm hoppiing JSPWiki
hasn't gotten to the point where people can't hack it anymore. If I'm
required to learn a number of new, complex tools I'll probably not have
the time either, such is my schedule of late.
Any suggestions on a fast(er) way through this? I'll take a look at
Admin.jsp, etc. Basically, if you have a roadmap on what actually needs
to be done (in some detail) I could better ascertain whether or not I'll
have time to do it. That roadmap would then enable me or someone else to
implement the idea.
Thanks,
Murray
...........................................................................
Murray Altheim <murray07 at altheim.com> === = =
http://www.altheim.com/murray/ = = ===
SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk = = = =
Boundless wind and moon - the eye within eyes,
Inexhaustible heaven and earth - the light beyond light,
The willow dark, the flower bright - ten thousand houses,
Knock at any door - there's one who will respond.
-- The Blue Cliff Record
Re: Broken Plugins
Posted by Murray Altheim <mu...@altheim.com>.
Dirk Frederickx wrote:
> I confirm that Table plugin is still working on v2.6.x or v2.7.x
I suspect this may be an instance of not having added the package to
the jspwiki.plugin.searchPath property in the WEB-INF/jspwiki.properties
file. If it's not there merely adding the jar file won't do anything.
Is this the case? or something more deeply mysterious?
Murray
...........................................................................
Murray Altheim <murray07 at altheim.com> === = =
http://www.altheim.com/murray/ = = ===
SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk = = = =
Boundless wind and moon - the eye within eyes,
Inexhaustible heaven and earth - the light beyond light,
The willow dark, the flower bright - ten thousand houses,
Knock at any door - there's one who will respond.
-- The Blue Cliff Record
Re: Broken Plugins
Posted by Dirk Frederickx <di...@gmail.com>.
I confirm that Table plugin is still working on v2.6.x or v2.7.x
dirk
On Thu, Jun 26, 2008 at 8:05 PM, Mattier, Ricardo
<Ri...@bcbsma.com> wrote:
>
> I'm at a total loss. What would I have to do to get JSPWiki to
> recognize the plugin?
>
> Rick M
>
>
>
> -----Original Message-----
> From: Harry Metske [mailto:harry.metske@gmail.com]
> Sent: Thursday, June 26, 2008 1:26 PM
> To: jspwiki-dev@incubator.apache.org
> Subject: Re: Broken Plugins
>
> the Table Plugin is a contributed plugin, the message in your log
> indicates
> that the plugin cannot be found while parsing a page.
>
> The source is in the svn repository, see instructions at:
> http://www.jspwiki.org/wiki/AnonymousCVSAccess
>
> regards,
> Harry
>
> 2008/6/26 Mattier, Ricardo <Ri...@bcbsma.com>:
>
>>
>> I noticed in the JSPWiki logs I received an error which reads:
>> 2008-06-26 11:45:15,542 [main] INFO
>> com.ecyrd.jspwiki.parser.JSPWikiMarkupParser - Failed to insert
>> plugin: Could not find plugin Table
>>
>> Can anyone point me in the right direction? I'm unable to find the
>> source for JSPWikiMarkupParser
>>
>> Rick M
>>
>>
>>
>>
>> -----Original Message-----
>> From: Mattier, Ricardo
>> Sent: Wednesday, June 25, 2008 1:19 PM
>> To: 'jspwiki-dev@incubator.apache.org'
>> Subject: RE: Broken Plugins
>>
>> Is the source available for the core plugins?
>>
>> Rick M.
>>
>>
>>
>> -----Original Message-----
>> From: Harry Metske [mailto:harry.metske@gmail.com]
>> Sent: Wednesday, June 25, 2008 1:13 PM
>> To: jspwiki-dev@incubator.apache.org
>> Subject: Re: Broken Plugins
>>
>> - If the plugin is core plugin (
>> http://www.jspwiki.org/wiki/JSPWikiCorePlugins) you can file a JIRA
>> issue,
>> and we will try to fix it.
>> - If it is a contributed plugin (
>> http://www.jspwiki.org/wiki/ContributedPlugins), you could contact the
>> guy
>> that donated it, or even better: fix it yourself and attach the fixed
>> version with the error-documentation to the page for the contributed
>> plugin
>> in question.
>> Or if you provide sufficient information (sources, stacktraces) maybe
>> someone on the list is willing to solve it for you.
>>
>> regards,
>> Harry
>>
>> 2008/6/25 Mattier, Ricardo <Ri...@bcbsma.com>:
>>
>> >
>> > There are some plugins that worked in the previous iterations
>> of
>> >
>> > JSPWiki such as [{Table}] which seem to be broken in 2.6.3. How
> should
>> > we go about fixing those plugins?
>> >
>> > Rick M
>> >
>> >
>> >
>> > This message is a PRIVATE communication.
>> > If you are not the intended recipient, please do not read, copy
>> > or use it and do not disclose it to others. Please notify the
>> > sender of the delivery error by replying to this message and then
>> > delete from your system. Thank you.
>> >
>>
>>
>>
>> --
>> met vriendelijke groet,
>> Harry Metske
>> Telnr. +31-548-512395
>> Mobile +31-6-51898081
>>
>> This message is a PRIVATE communication.
>> If you are not the intended recipient, please do not read, copy
>> or use it and do not disclose it to others. Please notify the
>> sender of the delivery error by replying to this message and then
>> delete from your system. Thank you.
>>
>
>
>
> --
> met vriendelijke groet,
> Harry Metske
> Telnr. +31-548-512395
> Mobile +31-6-51898081
>
> This message is a PRIVATE communication.
> If you are not the intended recipient, please do not read, copy
> or use it and do not disclose it to others. Please notify the
> sender of the delivery error by replying to this message and then
> delete from your system. Thank you.
>
Re: Broken Plugins
Posted by Harry Metske <ha...@gmail.com>.
The Table plugin is not a Core plugin, so it is not in
./WEB-INF/lib/JSPWiki.jar.
In your previous installation you probably downloaded the Table.jar file
from http://www.jspwiki.org/wiki/TablePlugin and put it in the WEB-INF/lib
directory. If the jar is there, JSPWiki should be able to find it.
regards,
Harry
2008/6/26 Mattier, Ricardo <Ri...@bcbsma.com>:
>
> I'm at a total loss. What would I have to do to get JSPWiki to
> recognize the plugin?
>
> Rick M
>
>
>
> -----Original Message-----
> From: Harry Metske [mailto:harry.metske@gmail.com]
> Sent: Thursday, June 26, 2008 1:26 PM
> To: jspwiki-dev@incubator.apache.org
> Subject: Re: Broken Plugins
>
> the Table Plugin is a contributed plugin, the message in your log
> indicates
> that the plugin cannot be found while parsing a page.
>
> The source is in the svn repository, see instructions at:
> http://www.jspwiki.org/wiki/AnonymousCVSAccess
>
> regards,
> Harry
>
> 2008/6/26 Mattier, Ricardo <Ri...@bcbsma.com>:
>
> >
> > I noticed in the JSPWiki logs I received an error which reads:
> > 2008-06-26 11:45:15,542 [main] INFO
> > com.ecyrd.jspwiki.parser.JSPWikiMarkupParser - Failed to insert
> > plugin: Could not find plugin Table
> >
> > Can anyone point me in the right direction? I'm unable to find the
> > source for JSPWikiMarkupParser
> >
> > Rick M
> >
> >
> >
> >
> > -----Original Message-----
> > From: Mattier, Ricardo
> > Sent: Wednesday, June 25, 2008 1:19 PM
> > To: 'jspwiki-dev@incubator.apache.org'
> > Subject: RE: Broken Plugins
> >
> > Is the source available for the core plugins?
> >
> > Rick M.
> >
> >
> >
> > -----Original Message-----
> > From: Harry Metske [mailto:harry.metske@gmail.com]
> > Sent: Wednesday, June 25, 2008 1:13 PM
> > To: jspwiki-dev@incubator.apache.org
> > Subject: Re: Broken Plugins
> >
> > - If the plugin is core plugin (
> > http://www.jspwiki.org/wiki/JSPWikiCorePlugins) you can file a JIRA
> > issue,
> > and we will try to fix it.
> > - If it is a contributed plugin (
> > http://www.jspwiki.org/wiki/ContributedPlugins), you could contact the
> > guy
> > that donated it, or even better: fix it yourself and attach the fixed
> > version with the error-documentation to the page for the contributed
> > plugin
> > in question.
> > Or if you provide sufficient information (sources, stacktraces) maybe
> > someone on the list is willing to solve it for you.
> >
> > regards,
> > Harry
> >
> > 2008/6/25 Mattier, Ricardo <Ri...@bcbsma.com>:
> >
> > >
> > > There are some plugins that worked in the previous iterations
> > of
> > >
> > > JSPWiki such as [{Table}] which seem to be broken in 2.6.3. How
> should
> > > we go about fixing those plugins?
> > >
> > > Rick M
> > >
> > >
> > >
> > > This message is a PRIVATE communication.
> > > If you are not the intended recipient, please do not read, copy
> > > or use it and do not disclose it to others. Please notify the
> > > sender of the delivery error by replying to this message and then
> > > delete from your system. Thank you.
> > >
> >
> >
> >
> > --
> > met vriendelijke groet,
> > Harry Metske
> > Telnr. +31-548-512395
> > Mobile +31-6-51898081
> >
> > This message is a PRIVATE communication.
> > If you are not the intended recipient, please do not read, copy
> > or use it and do not disclose it to others. Please notify the
> > sender of the delivery error by replying to this message and then
> > delete from your system. Thank you.
> >
>
>
>
> --
> met vriendelijke groet,
> Harry Metske
> Telnr. +31-548-512395
> Mobile +31-6-51898081
>
> This message is a PRIVATE communication.
> If you are not the intended recipient, please do not read, copy
> or use it and do not disclose it to others. Please notify the
> sender of the delivery error by replying to this message and then
> delete from your system. Thank you.
>
--
met vriendelijke groet,
Harry Metske
Telnr. +31-548-512395
Mobile +31-6-51898081
RE: Broken Plugins
Posted by "Mattier, Ricardo" <Ri...@bcbsma.com>.
I'm at a total loss. What would I have to do to get JSPWiki to
recognize the plugin?
Rick M
-----Original Message-----
From: Harry Metske [mailto:harry.metske@gmail.com]
Sent: Thursday, June 26, 2008 1:26 PM
To: jspwiki-dev@incubator.apache.org
Subject: Re: Broken Plugins
the Table Plugin is a contributed plugin, the message in your log
indicates
that the plugin cannot be found while parsing a page.
The source is in the svn repository, see instructions at:
http://www.jspwiki.org/wiki/AnonymousCVSAccess
regards,
Harry
2008/6/26 Mattier, Ricardo <Ri...@bcbsma.com>:
>
> I noticed in the JSPWiki logs I received an error which reads:
> 2008-06-26 11:45:15,542 [main] INFO
> com.ecyrd.jspwiki.parser.JSPWikiMarkupParser - Failed to insert
> plugin: Could not find plugin Table
>
> Can anyone point me in the right direction? I'm unable to find the
> source for JSPWikiMarkupParser
>
> Rick M
>
>
>
>
> -----Original Message-----
> From: Mattier, Ricardo
> Sent: Wednesday, June 25, 2008 1:19 PM
> To: 'jspwiki-dev@incubator.apache.org'
> Subject: RE: Broken Plugins
>
> Is the source available for the core plugins?
>
> Rick M.
>
>
>
> -----Original Message-----
> From: Harry Metske [mailto:harry.metske@gmail.com]
> Sent: Wednesday, June 25, 2008 1:13 PM
> To: jspwiki-dev@incubator.apache.org
> Subject: Re: Broken Plugins
>
> - If the plugin is core plugin (
> http://www.jspwiki.org/wiki/JSPWikiCorePlugins) you can file a JIRA
> issue,
> and we will try to fix it.
> - If it is a contributed plugin (
> http://www.jspwiki.org/wiki/ContributedPlugins), you could contact the
> guy
> that donated it, or even better: fix it yourself and attach the fixed
> version with the error-documentation to the page for the contributed
> plugin
> in question.
> Or if you provide sufficient information (sources, stacktraces) maybe
> someone on the list is willing to solve it for you.
>
> regards,
> Harry
>
> 2008/6/25 Mattier, Ricardo <Ri...@bcbsma.com>:
>
> >
> > There are some plugins that worked in the previous iterations
> of
> >
> > JSPWiki such as [{Table}] which seem to be broken in 2.6.3. How
should
> > we go about fixing those plugins?
> >
> > Rick M
> >
> >
> >
> > This message is a PRIVATE communication.
> > If you are not the intended recipient, please do not read, copy
> > or use it and do not disclose it to others. Please notify the
> > sender of the delivery error by replying to this message and then
> > delete from your system. Thank you.
> >
>
>
>
> --
> met vriendelijke groet,
> Harry Metske
> Telnr. +31-548-512395
> Mobile +31-6-51898081
>
> This message is a PRIVATE communication.
> If you are not the intended recipient, please do not read, copy
> or use it and do not disclose it to others. Please notify the
> sender of the delivery error by replying to this message and then
> delete from your system. Thank you.
>
--
met vriendelijke groet,
Harry Metske
Telnr. +31-548-512395
Mobile +31-6-51898081
This message is a PRIVATE communication.
If you are not the intended recipient, please do not read, copy
or use it and do not disclose it to others. Please notify the
sender of the delivery error by replying to this message and then
delete from your system. Thank you.
Re: Broken Plugins
Posted by Harry Metske <ha...@gmail.com>.
the Table Plugin is a contributed plugin, the message in your log indicates
that the plugin cannot be found while parsing a page.
The source is in the svn repository, see instructions at:
http://www.jspwiki.org/wiki/AnonymousCVSAccess
regards,
Harry
2008/6/26 Mattier, Ricardo <Ri...@bcbsma.com>:
>
> I noticed in the JSPWiki logs I received an error which reads:
> 2008-06-26 11:45:15,542 [main] INFO
> com.ecyrd.jspwiki.parser.JSPWikiMarkupParser - Failed to insert
> plugin: Could not find plugin Table
>
> Can anyone point me in the right direction? I'm unable to find the
> source for JSPWikiMarkupParser
>
> Rick M
>
>
>
>
> -----Original Message-----
> From: Mattier, Ricardo
> Sent: Wednesday, June 25, 2008 1:19 PM
> To: 'jspwiki-dev@incubator.apache.org'
> Subject: RE: Broken Plugins
>
> Is the source available for the core plugins?
>
> Rick M.
>
>
>
> -----Original Message-----
> From: Harry Metske [mailto:harry.metske@gmail.com]
> Sent: Wednesday, June 25, 2008 1:13 PM
> To: jspwiki-dev@incubator.apache.org
> Subject: Re: Broken Plugins
>
> - If the plugin is core plugin (
> http://www.jspwiki.org/wiki/JSPWikiCorePlugins) you can file a JIRA
> issue,
> and we will try to fix it.
> - If it is a contributed plugin (
> http://www.jspwiki.org/wiki/ContributedPlugins), you could contact the
> guy
> that donated it, or even better: fix it yourself and attach the fixed
> version with the error-documentation to the page for the contributed
> plugin
> in question.
> Or if you provide sufficient information (sources, stacktraces) maybe
> someone on the list is willing to solve it for you.
>
> regards,
> Harry
>
> 2008/6/25 Mattier, Ricardo <Ri...@bcbsma.com>:
>
> >
> > There are some plugins that worked in the previous iterations
> of
> >
> > JSPWiki such as [{Table}] which seem to be broken in 2.6.3. How should
> > we go about fixing those plugins?
> >
> > Rick M
> >
> >
> >
> > This message is a PRIVATE communication.
> > If you are not the intended recipient, please do not read, copy
> > or use it and do not disclose it to others. Please notify the
> > sender of the delivery error by replying to this message and then
> > delete from your system. Thank you.
> >
>
>
>
> --
> met vriendelijke groet,
> Harry Metske
> Telnr. +31-548-512395
> Mobile +31-6-51898081
>
> This message is a PRIVATE communication.
> If you are not the intended recipient, please do not read, copy
> or use it and do not disclose it to others. Please notify the
> sender of the delivery error by replying to this message and then
> delete from your system. Thank you.
>
--
met vriendelijke groet,
Harry Metske
Telnr. +31-548-512395
Mobile +31-6-51898081
Re: Broken Plugins
Posted by Harry Metske <ha...@gmail.com>.
yes, this is (together with all the jspwiki sources) in the svn repository,
see for further instructions:
http://www.jspwiki.org/wiki/AnonymousCVSAccess
regards,
Harry
2008/6/25 Mattier, Ricardo <Ri...@bcbsma.com>:
>
> Is the source available for the core plugins?
>
> Rick M.
>
>
>
> -----Original Message-----
> From: Harry Metske [mailto:harry.metske@gmail.com]
> Sent: Wednesday, June 25, 2008 1:13 PM
> To: jspwiki-dev@incubator.apache.org
> Subject: Re: Broken Plugins
>
> - If the plugin is core plugin (
> http://www.jspwiki.org/wiki/JSPWikiCorePlugins) you can file a JIRA
> issue,
> and we will try to fix it.
> - If it is a contributed plugin (
> http://www.jspwiki.org/wiki/ContributedPlugins), you could contact the
> guy
> that donated it, or even better: fix it yourself and attach the fixed
> version with the error-documentation to the page for the contributed
> plugin
> in question.
> Or if you provide sufficient information (sources, stacktraces) maybe
> someone on the list is willing to solve it for you.
>
> regards,
> Harry
>
> 2008/6/25 Mattier, Ricardo <Ri...@bcbsma.com>:
>
> >
> > There are some plugins that worked in the previous iterations
> of
> >
> > JSPWiki such as [{Table}] which seem to be broken in 2.6.3. How should
> > we go about fixing those plugins?
> >
> > Rick M
> >
> >
> >
> > This message is a PRIVATE communication.
> > If you are not the intended recipient, please do not read, copy
> > or use it and do not disclose it to others. Please notify the
> > sender of the delivery error by replying to this message and then
> > delete from your system. Thank you.
> >
>
>
>
> --
> met vriendelijke groet,
> Harry Metske
> Telnr. +31-548-512395
> Mobile +31-6-51898081
>
> This message is a PRIVATE communication.
> If you are not the intended recipient, please do not read, copy
> or use it and do not disclose it to others. Please notify the
> sender of the delivery error by replying to this message and then
> delete from your system. Thank you.
>
--
met vriendelijke groet,
Harry Metske
Telnr. +31-548-512395
Mobile +31-6-51898081
RE: Broken Plugins
Posted by "Mattier, Ricardo" <Ri...@bcbsma.com>.
Is the source available for the core plugins?
Rick M.
-----Original Message-----
From: Harry Metske [mailto:harry.metske@gmail.com]
Sent: Wednesday, June 25, 2008 1:13 PM
To: jspwiki-dev@incubator.apache.org
Subject: Re: Broken Plugins
- If the plugin is core plugin (
http://www.jspwiki.org/wiki/JSPWikiCorePlugins) you can file a JIRA
issue,
and we will try to fix it.
- If it is a contributed plugin (
http://www.jspwiki.org/wiki/ContributedPlugins), you could contact the
guy
that donated it, or even better: fix it yourself and attach the fixed
version with the error-documentation to the page for the contributed
plugin
in question.
Or if you provide sufficient information (sources, stacktraces) maybe
someone on the list is willing to solve it for you.
regards,
Harry
2008/6/25 Mattier, Ricardo <Ri...@bcbsma.com>:
>
> There are some plugins that worked in the previous iterations
of
>
> JSPWiki such as [{Table}] which seem to be broken in 2.6.3. How should
> we go about fixing those plugins?
>
> Rick M
>
>
>
> This message is a PRIVATE communication.
> If you are not the intended recipient, please do not read, copy
> or use it and do not disclose it to others. Please notify the
> sender of the delivery error by replying to this message and then
> delete from your system. Thank you.
>
--
met vriendelijke groet,
Harry Metske
Telnr. +31-548-512395
Mobile +31-6-51898081
This message is a PRIVATE communication.
If you are not the intended recipient, please do not read, copy
or use it and do not disclose it to others. Please notify the
sender of the delivery error by replying to this message and then
delete from your system. Thank you.
RE: Broken Plugins
Posted by "Mattier, Ricardo" <Ri...@bcbsma.com>.
I noticed in the JSPWiki logs I received an error which reads:
2008-06-26 11:45:15,542 [main] INFO
com.ecyrd.jspwiki.parser.JSPWikiMarkupParser - Failed to insert
plugin: Could not find plugin Table
Can anyone point me in the right direction? I'm unable to find the
source for JSPWikiMarkupParser
Rick M
-----Original Message-----
From: Mattier, Ricardo
Sent: Wednesday, June 25, 2008 1:19 PM
To: 'jspwiki-dev@incubator.apache.org'
Subject: RE: Broken Plugins
Is the source available for the core plugins?
Rick M.
-----Original Message-----
From: Harry Metske [mailto:harry.metske@gmail.com]
Sent: Wednesday, June 25, 2008 1:13 PM
To: jspwiki-dev@incubator.apache.org
Subject: Re: Broken Plugins
- If the plugin is core plugin (
http://www.jspwiki.org/wiki/JSPWikiCorePlugins) you can file a JIRA
issue,
and we will try to fix it.
- If it is a contributed plugin (
http://www.jspwiki.org/wiki/ContributedPlugins), you could contact the
guy
that donated it, or even better: fix it yourself and attach the fixed
version with the error-documentation to the page for the contributed
plugin
in question.
Or if you provide sufficient information (sources, stacktraces) maybe
someone on the list is willing to solve it for you.
regards,
Harry
2008/6/25 Mattier, Ricardo <Ri...@bcbsma.com>:
>
> There are some plugins that worked in the previous iterations
of
>
> JSPWiki such as [{Table}] which seem to be broken in 2.6.3. How should
> we go about fixing those plugins?
>
> Rick M
>
>
>
> This message is a PRIVATE communication.
> If you are not the intended recipient, please do not read, copy
> or use it and do not disclose it to others. Please notify the
> sender of the delivery error by replying to this message and then
> delete from your system. Thank you.
>
--
met vriendelijke groet,
Harry Metske
Telnr. +31-548-512395
Mobile +31-6-51898081
This message is a PRIVATE communication.
If you are not the intended recipient, please do not read, copy
or use it and do not disclose it to others. Please notify the
sender of the delivery error by replying to this message and then
delete from your system. Thank you.
Re: Broken Plugins
Posted by Harry Metske <ha...@gmail.com>.
- If the plugin is core plugin (
http://www.jspwiki.org/wiki/JSPWikiCorePlugins) you can file a JIRA issue,
and we will try to fix it.
- If it is a contributed plugin (
http://www.jspwiki.org/wiki/ContributedPlugins), you could contact the guy
that donated it, or even better: fix it yourself and attach the fixed
version with the error-documentation to the page for the contributed plugin
in question.
Or if you provide sufficient information (sources, stacktraces) maybe
someone on the list is willing to solve it for you.
regards,
Harry
2008/6/25 Mattier, Ricardo <Ri...@bcbsma.com>:
>
> There are some plugins that worked in the previous iterations of
>
> JSPWiki such as [{Table}] which seem to be broken in 2.6.3. How should
> we go about fixing those plugins?
>
> Rick M
>
>
>
> This message is a PRIVATE communication.
> If you are not the intended recipient, please do not read, copy
> or use it and do not disclose it to others. Please notify the
> sender of the delivery error by replying to this message and then
> delete from your system. Thank you.
>
--
met vriendelijke groet,
Harry Metske
Telnr. +31-548-512395
Mobile +31-6-51898081
Re: Broken Plugins
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
On Jun 25, 2008, at 16:58 , Mattier, Ricardo wrote:
>
> There are some plugins that worked in the previous iterations of
>
> JSPWiki such as [{Table}] which seem to be broken in 2.6.3. How should
> we go about fixing those plugins?
Good question. Can you take ownership of the process of updating the
plugins?
/Janne
Broken Plugins
Posted by "Mattier, Ricardo" <Ri...@bcbsma.com>.
There are some plugins that worked in the previous iterations of
JSPWiki such as [{Table}] which seem to be broken in 2.6.3. How should
we go about fixing those plugins?
Rick M
This message is a PRIVATE communication.
If you are not the intended recipient, please do not read, copy
or use it and do not disclose it to others. Please notify the
sender of the delivery error by replying to this message and then
delete from your system. Thank you.
Re: Controllable API
Posted by Murray Altheim <mu...@altheim.com>.
Mattier, Ricardo wrote:
> There are some plugins that worked in the previous iterations of JSPWiki
> such as [{Table}] which seem to be broken in 2.6.3. How should we go
> about fixing those plugins?
Rick,
Could you start a new thread when you start a new subject? It's hard
to track issues otherwise.
Thanks,
Murray
...........................................................................
Murray Altheim <murray07 at altheim.com> === = =
http://www.altheim.com/murray/ = = ===
SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk = = = =
Boundless wind and moon - the eye within eyes,
Inexhaustible heaven and earth - the light beyond light,
The willow dark, the flower bright - ten thousand houses,
Knock at any door - there's one who will respond.
-- The Blue Cliff Record
RE: Controllable API
Posted by "Mattier, Ricardo" <Ri...@bcbsma.com>.
There are some plugins that worked in the previous iterations of JSPWiki
such as [{Table}] which seem to be broken in 2.6.3. How should we go
about fixing those plugins?
Rick M.
-----Original Message-----
From: Janne Jalkanen [mailto:Janne.Jalkanen@ecyrd.com]
Sent: Wednesday, June 25, 2008 3:22 AM
To: jspwiki-dev@incubator.apache.org
Subject: Re: Controllable API
> Except I just realized that there might be a requirement for
> dependency
> management. For example, a large number of my plugins are queries of
> one sort or another, so they often extend QueryPlugin, or extend an
> extension of QueryPlugin. If an admin turned off QueryPlugin a whole
> lot of plugins would fail, and relatively inexplicably. Perhaps a
> simple
> reflection check of what the plugin extends would work, or just rely
> on documentation, which is perhaps not as elegant but gets us to a
> solution a lot faster.
I think this sounds like overengineering. Your plugins should check
for this sort of stuff on their own, and log/output stuff when they
are being used. If you start doing dependency management inside the
JSPWiki code, you'll probably end up shooting yourself in the foot
with circular references and really complex boolean logic.
Just try shooting for something really simple.
/Janne
This message is a PRIVATE communication.
If you are not the intended recipient, please do not read, copy
or use it and do not disclose it to others. Please notify the
sender of the delivery error by replying to this message and then
delete from your system. Thank you.
Re: Controllable API
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
> Except I just realized that there might be a requirement for
> dependency
> management. For example, a large number of my plugins are queries of
> one sort or another, so they often extend QueryPlugin, or extend an
> extension of QueryPlugin. If an admin turned off QueryPlugin a whole
> lot of plugins would fail, and relatively inexplicably. Perhaps a
> simple
> reflection check of what the plugin extends would work, or just rely
> on documentation, which is perhaps not as elegant but gets us to a
> solution a lot faster.
I think this sounds like overengineering. Your plugins should check
for this sort of stuff on their own, and log/output stuff when they
are being used. If you start doing dependency management inside the
JSPWiki code, you'll probably end up shooting yourself in the foot
with circular references and really complex boolean logic.
Just try shooting for something really simple.
/Janne
Re: Controllable API
Posted by Murray Altheim <mu...@altheim.com>.
Janne Jalkanen wrote:
>> If I were to create a jspwiki_module.xml file for all of the plugins
>> I administer (and provide XML files for all jars I distribute), then
>> it'd be a matter of adding a single element (e.g., <enabled>, or
>> perhaps an ACL-based approach) to the XML, adding the rather minor
>> changes to com.ecyrd.jspwiki.ui.admin.beans.PluginBean to process the
>> new boolean or ACL value(s), and add the necessary functionality to
>> Admin.jsp to permit more than the current read-only display, instead
>> including a checkbox (boolean) or selector (ACL) for each plugin.
>>
>> Is this close to what's needed, or is there a lot more?
>
> That's pretty much it... :-)
Except I just realized that there might be a requirement for dependency
management. For example, a large number of my plugins are queries of
one sort or another, so they often extend QueryPlugin, or extend an
extension of QueryPlugin. If an admin turned off QueryPlugin a whole
lot of plugins would fail, and relatively inexplicably. Perhaps a simple
reflection check of what the plugin extends would work, or just rely
on documentation, which is perhaps not as elegant but gets us to a
solution a lot faster.
> You might actually want to store the "enabled/disabled" status elsehwere
> than in the jspwiki_module.xml, or else it won't be persisted across
> restarts. So I would recommend the workdir and store it in there in
> some sort of a preferences object. (Hmm, we already seem to have
> com.ecyrd.jspwiki.preferences... Anyhoo, this is something that
> actually does need a bit of thinking - currently the reason why
> Admin.jsp does not store any values is because of the fact that I could
> never really figure out what the proper storage should be, and how that
> should relate to the jspwiki.properties and filters.xml files.)
Okay, will look into that. I agree -- the XML file should be an initial
set of settings but I wouldn't want to write to it. What I do in my
Ceryle application is read an XML properties file but write it back
out using its native format with .prefs extension. The presence of the
prefs file tells the app to read it instead of the properties file. I
could mimic that behaviour pretty easily.
<properties>
<entry key="http://purl.org/ceryle/prop/#author"></entry>
<entry key="http://purl.org/ceryle/prop/#restoreSession">false</entry>
</properties>
http\://purl.org/ceryle/prop/\#author=Murray Altheim
http\://purl.org/ceryle/prop/\#restoreSession=true
>> [I'm also curious as to how the 'alias' feature works, as I currently
>> have a fair number of classes whose sole purpose is to provide an
>> alias so that users don't have to type "Plugin" appended to what is
>> basically a predicate name). Are multiple alii possible?]
>
> At this moment, no, but it should be an easy enough extension. Needs
> changing of the WikiPluginInfo API though.
I'll look into that as well -- sounds like it would be permitting
multiple <alias> elements or something akin.
Murray
...........................................................................
Murray Altheim <murray07 at altheim.com> === = =
http://www.altheim.com/murray/ = = ===
SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk = = = =
Boundless wind and moon - the eye within eyes,
Inexhaustible heaven and earth - the light beyond light,
The willow dark, the flower bright - ten thousand houses,
Knock at any door - there's one who will respond.
-- The Blue Cliff Record
Re: Controllable API
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
> If I were to create a jspwiki_module.xml file for all of the plugins
> I administer (and provide XML files for all jars I distribute), then
> it'd be a matter of adding a single element (e.g., <enabled>, or
> perhaps an ACL-based approach) to the XML, adding the rather minor
> changes to com.ecyrd.jspwiki.ui.admin.beans.PluginBean to process the
> new boolean or ACL value(s), and add the necessary functionality to
> Admin.jsp to permit more than the current read-only display, instead
> including a checkbox (boolean) or selector (ACL) for each plugin.
>
> Is this close to what's needed, or is there a lot more?
That's pretty much it... :-)
You might actually want to store the "enabled/disabled" status
elsehwere than in the jspwiki_module.xml, or else it won't be
persisted across restarts. So I would recommend the workdir and
store it in there in some sort of a preferences object. (Hmm, we
already seem to have com.ecyrd.jspwiki.preferences... Anyhoo, this
is something that actually does need a bit of thinking - currently
the reason why Admin.jsp does not store any values is because of the
fact that I could never really figure out what the proper storage
should be, and how that should relate to the jspwiki.properties and
filters.xml files.)
> [I'm also curious as to how the 'alias' feature works, as I currently
> have a fair number of classes whose sole purpose is to provide an
> alias so that users don't have to type "Plugin" appended to what is
> basically a predicate name). Are multiple alii possible?]
At this moment, no, but it should be an easy enough extension. Needs
changing of the WikiPluginInfo API though.
/Janne
Re: Controllable API
Posted by Murray Altheim <mu...@altheim.com>.
Janne,
Okay, a bit of RTFM for me. I'm curious as to why there'd need to be
much if anything by way of new machinery, as the Admin UI seems to be
*almost* there already.
If I were to create a jspwiki_module.xml file for all of the plugins
I administer (and provide XML files for all jars I distribute), then
it'd be a matter of adding a single element (e.g., <enabled>, or
perhaps an ACL-based approach) to the XML, adding the rather minor
changes to com.ecyrd.jspwiki.ui.admin.beans.PluginBean to process the
new boolean or ACL value(s), and add the necessary functionality to
Admin.jsp to permit more than the current read-only display, instead
including a checkbox (boolean) or selector (ACL) for each plugin.
Is this close to what's needed, or is there a lot more?
[I'm also curious as to how the 'alias' feature works, as I currently
have a fair number of classes whose sole purpose is to provide an
alias so that users don't have to type "Plugin" appended to what is
basically a predicate name). Are multiple alii possible?]
Thanks,
Murray
...........................................................................
Murray Altheim <murray07 at altheim.com> === = =
http://www.altheim.com/murray/ = = ===
SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk = = = =
Boundless wind and moon - the eye within eyes,
Inexhaustible heaven and earth - the light beyond light,
The willow dark, the flower bright - ten thousand houses,
Knock at any door - there's one who will respond.
-- The Blue Cliff Record
RE: Controllable API
Posted by "Mattier, Ricardo" <Ri...@bcbsma.com>.
-----Original Message-----
From: Janne Jalkanen [mailto:Janne.Jalkanen@ecyrd.com]
Sent: Tuesday, June 24, 2008 3:14 PM
To: jspwiki-dev@incubator.apache.org
Subject: Re: Controllable API
Yup. This is a bit confusing, but all of our AdminBeans actually
implement DynamicMBean by extending from
com.ecyrd.management.SimpleMBean. I wasn't quite sure how to make
the inheritance graphs build (and still make it compile for JDK4,
which is no longer an issue).
If you fire up jconsole and watch, you'll see all the same
functionalities appear also as JMX beans as in the HTML interface. I
just want to have a better admin UI (think Wordpress) than what the
basic JMX functionality offers.
/Janne
On 24 Jun 2008, at 20:59, Andrew Jaquith wrote:
> The idea is a good one. With respect to implementation, it seems to
> me we should probably look into JMX for this. JMX defines a
> lifecycle for registering managed beans.
>
> On Jun 24, 2008, at 1:52 PM, Janne Jalkanen wrote:
>
>>> It occurs to me to create a very simple "Controllable" API and
>>> add a minor callout in the PluginManager to disable the function
>>> of a plugin based on it occurring in an excluded list, or enable
>>> it based on an included list (either? both?). A disabled plugin
>>> would either be entirely ignored by the parser/PluginManager,
>>> return an empty string, or some kind of error message (this might
>>> be defined by the API). I'm thinking of writing some kind of UI
>>> or JSP to permit an administrator to individually set a flag for
>>> each plugin.
>>
>> I was actually going to do something like that but sort of ran out
>> of time. Admin.jsp allows you to list all the installed plugins,
>> and the idea was that you could turn plugins (well, any kind of
>> modules: filters, editors, etc) on and off from there.
>>
>> Essentially it would mean a new field in the WikiModuleInfo, and
>> necessary code in the PluginManager. I would most prefer if the
>> UI were in the form of an AdminBean.
>>
>> Could be targeted for 2.8.x, x >=1.
>>
>> /Janne
This message is a PRIVATE communication.
If you are not the intended recipient, please do not read, copy
or use it and do not disclose it to others. Please notify the
sender of the delivery error by replying to this message and then
delete from your system. Thank you.
Re: Controllable API
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
Yup. This is a bit confusing, but all of our AdminBeans actually
implement DynamicMBean by extending from
com.ecyrd.management.SimpleMBean. I wasn't quite sure how to make
the inheritance graphs build (and still make it compile for JDK4,
which is no longer an issue).
If you fire up jconsole and watch, you'll see all the same
functionalities appear also as JMX beans as in the HTML interface. I
just want to have a better admin UI (think Wordpress) than what the
basic JMX functionality offers.
/Janne
On 24 Jun 2008, at 20:59, Andrew Jaquith wrote:
> The idea is a good one. With respect to implementation, it seems to
> me we should probably look into JMX for this. JMX defines a
> lifecycle for registering managed beans.
>
> On Jun 24, 2008, at 1:52 PM, Janne Jalkanen wrote:
>
>>> It occurs to me to create a very simple "Controllable" API and
>>> add a minor callout in the PluginManager to disable the function
>>> of a plugin based on it occurring in an excluded list, or enable
>>> it based on an included list (either? both?). A disabled plugin
>>> would either be entirely ignored by the parser/PluginManager,
>>> return an empty string, or some kind of error message (this might
>>> be defined by the API). I'm thinking of writing some kind of UI
>>> or JSP to permit an administrator to individually set a flag for
>>> each plugin.
>>
>> I was actually going to do something like that but sort of ran out
>> of time. Admin.jsp allows you to list all the installed plugins,
>> and the idea was that you could turn plugins (well, any kind of
>> modules: filters, editors, etc) on and off from there.
>>
>> Essentially it would mean a new field in the WikiModuleInfo, and
>> necessary code in the PluginManager. I would most prefer if the
>> UI were in the form of an AdminBean.
>>
>> Could be targeted for 2.8.x, x >=1.
>>
>> /Janne
Re: Controllable API
Posted by Andrew Jaquith <an...@mac.com>.
The idea is a good one. With respect to implementation, it seems to me
we should probably look into JMX for this. JMX defines a lifecycle for
registering managed beans.
On Jun 24, 2008, at 1:52 PM, Janne Jalkanen wrote:
>> It occurs to me to create a very simple "Controllable" API and
>> add a minor callout in the PluginManager to disable the function
>> of a plugin based on it occurring in an excluded list, or enable
>> it based on an included list (either? both?). A disabled plugin
>> would either be entirely ignored by the parser/PluginManager,
>> return an empty string, or some kind of error message (this might
>> be defined by the API). I'm thinking of writing some kind of UI
>> or JSP to permit an administrator to individually set a flag for
>> each plugin.
>
> I was actually going to do something like that but sort of ran out
> of time. Admin.jsp allows you to list all the installed plugins,
> and the idea was that you could turn plugins (well, any kind of
> modules: filters, editors, etc) on and off from there.
>
> Essentially it would mean a new field in the WikiModuleInfo, and
> necessary code in the PluginManager. I would most prefer if the UI
> were in the form of an AdminBean.
>
> Could be targeted for 2.8.x, x >=1.
>
> /Janne
Re: Controllable API
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
> It occurs to me to create a very simple "Controllable" API and
> add a minor callout in the PluginManager to disable the function
> of a plugin based on it occurring in an excluded list, or enable
> it based on an included list (either? both?). A disabled plugin
> would either be entirely ignored by the parser/PluginManager,
> return an empty string, or some kind of error message (this might
> be defined by the API). I'm thinking of writing some kind of UI
> or JSP to permit an administrator to individually set a flag for
> each plugin.
I was actually going to do something like that but sort of ran out of
time. Admin.jsp allows you to list all the installed plugins, and
the idea was that you could turn plugins (well, any kind of modules:
filters, editors, etc) on and off from there.
Essentially it would mean a new field in the WikiModuleInfo, and
necessary code in the PluginManager. I would most prefer if the UI
were in the form of an AdminBean.
Could be targeted for 2.8.x, x >=1.
/Janne
Re: Controllable API
Posted by Harry Metske <ha...@gmail.com>.
sounds like a good idea. Providing plugins through (dynamic runtime)
configuration instead of by including or excluding them from a piece of
software we ship.
This piece of code maybe should discover which plugins are available and
show them on a nice JSP page where you as administrator can decide which
ones to enable/disable.
Maybe that would open up the door to some more plugin configuration, for
example who is authorized to use a certain plugin (depending on a J2EE role
he/she has).
Actually I was working on a new prototype plugin, that I named
WikiPageStatPlugin (
http://www.computerhok.nl/JSPWiki/Wiki.jsp?page=TestWikiPageStatPlugin ).
An example of something that you don't want every normal user to use, but
more for an administrator.
regards,
Harry
2008/6/24 Murray Altheim <mu...@altheim.com>:
> Not that anyone is paying that close attention, but if you have
> you'd note that I'm managing a LOT of plugins. They're growing
> like fungus around here. Now, I'm not trying to offload them but
> my time lately has been very tight and testing has been a pain
> since my typical build installation includes all of them, such
> that I'm never sure of interactions. Lately I've been getting
> ping'd on a number of different plugin packages that have been
> bundled in the large CeryleWiki plugins jar file. I should
> probably break that thing into much smaller jars. Time willing...
>
> It occurs to me to create a very simple "Controllable" API and
> add a minor callout in the PluginManager to disable the function
> of a plugin based on it occurring in an excluded list, or enable
> it based on an included list (either? both?). A disabled plugin
> would either be entirely ignored by the parser/PluginManager,
> return an empty string, or some kind of error message (this might
> be defined by the API). I'm thinking of writing some kind of UI
> or JSP to permit an administrator to individually set a flag for
> each plugin.
>
> Any thoughts on this? Bad idea? Good idea? Not an interesting
> idea? When might this might make sense, JSPWiki-version-wise?
>
> Thanks,
>
> Murray
>
> ...........................................................................
> Murray Altheim <murray07 at altheim.com> === =
> =
> http://www.altheim.com/murray/ = =
> ===
> SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk = = = =
>
> Boundless wind and moon - the eye within eyes,
> Inexhaustible heaven and earth - the light beyond light,
> The willow dark, the flower bright - ten thousand houses,
> Knock at any door - there's one who will respond.
> -- The Blue Cliff Record
>
--
met vriendelijke groet,
Harry Metske
Telnr. +31-548-512395
Mobile +31-6-51898081