addresses (regexes) to
> ban.
>
> regards,
> Harry
>
>
> On 3 February 2016 at 21:44, Ichiro Furusato
> wrote:
>
> > Hi Harry,
> >
> > A note out of the blue perhaps, but at one point I modified one of our
> > PageProviders to have a simple admin flag
Hi Harry,
A note out of the blue perhaps, but at one point I modified one of our
PageProviders to have a simple admin flag that if set kept pages from
being saved. It was used in emergencies of the sort you've mentioned.
It could be added to the API and provided with an additional isLocked()
meth
Hi Harry,
Just a quick question: do you see any security issues that may arise by
this practice? if so,
how might these be mitigated?
I'm thinking in particular of how someone might introduce a vulnerability
in JSPWiki by
intercepting the startup script and setting an environment variable to
alte
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
Hi,
Not sure if anyone is interested in this. I had a brief spurt of work on
doing something
I've been meaning to do for years, namely, removing the versioning-related
methods
from WikiPageProvider and the JSPWiki implementations of the provider, and
moving
that functionality to the VersioningProv
Hi,
Just coming up for air, thought I'd throw what might seem a random question
into
the group, as I'm working on a WikiPageProvider implementation.
It appears that the movePage() method makes absolutely no checks prior to
moving (renaming) a wiki page. In other words, moving/renaming a page to
t
/jira/browse/JSPWIKI-811
> > Project: JSPWiki
> > Issue Type: Improvement
> > Components: Default template
> >Reporter: Ichiro Furusato
> > Labels: javascript
> > Fix For: FutureVersion
> >
If it's any help, we've developed a provider where *everything* is a page
property, including
the text of the page. We've found this approach mirrors what a lot of
digital libraries do, and
has the advantage of treating all data as metadata. By not differentiating
data from metadata
we end up with
Hi,
I've been playing around with WikiPage objects lately and noted that
the constructor includes the parent WikiEngine. This has been true so
far as I know for the life of the project. The JSPWiki isn't particularly
clean in this regard so this would be (IMO) categorised as an API
cleanup.
I'd l
We rely on various features of XHTML being parsable as XML, so HTML 5 as a
default would be a real problem.
HTML 5 is not a document format, it is a browser feature/compatibility
guideline (IMO).
This conclusion is not for lack of analysis, witness:
http://sourceforge.net/p/saxon/mailman/messa
Hi Juan Pablo,
The upgrade to EHCache seems pretty painless. The current trunk is on
version
2.6.6,from May 2013. So it's not terribly old but my understanding is a)
the API
has changed a bit, and b) EHCache is no longer distributed as an
ehcache-core
module in contemporary versions.
This may not
+1
FWIW (from a non-voter), I downloaded and successfully built 2.10.1, then
installed
it on a server. I then installed:
* the Neocortext wiki plugins
* the Neocortext JsonPageProvider
* 7 additional dependency jars (e.g., guava, joda-time).
* various prototype skins (including CleanBlue)
I'm actually kinda waiting until HADDOCK is finished as I may consider
making a CleanBlue
version based on it, depending on time available. We have started on a
tablet version of
CleanBlue but it's unfinished (as CleanBlue was itself a moving target). We
may revive the
tablet version of CleanBlue a
Have you seen the one used for the CleanBlue skin? I can supply it as an
SVG if
necessary.
Ichiro
On Thu, Mar 20, 2014 at 8:54 AM, Siegfried Goeschl wrote:
> Hi folks,
>
> minor thing - is there any high-quality JSPWiki logo somewhere - maybe on
> some hard disk :-)
>
> Thanks in advance
>
>
Hi Brian,
Having recently attended a session on security exploits in the JDK I'm
realising the extent
of possible security issues in JSPWiki by opening up the possibility of
external jars and
external configuration, not to mention plugins. For plugins that by their
nature have security
issues (suc
[
https://issues.apache.org/jira/browse/JSPWIKI-822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13911442#comment-13911442
]
Ichiro Furusato commented on JSPWIKI-822:
-
I have patched my own copy with
Ichiro Furusato created JSPWIKI-822:
---
Summary: NPE thrown by PluginContext#getText()
Key: JSPWIKI-822
URL: https://issues.apache.org/jira/browse/JSPWIKI-822
Project: JSPWiki
Issue Type
Hi all,
To give you an idea of this kind of thing, we have been doing a similar
trick with a single
Maven pom.xml file configured for Jetty, with a webapp (e.g., JSPWiki) in
the
./src/main/webapps directory.
You type 'mvn jetty:run', Maven does its magic by downloading 90% of the
Internet, and
in
Hi Harry,
I can't honestly say. But I just added a printout of the list of objects in
the global
registry in the JSONRPCManager, and all of my registrations (of plugins as
well
as singleton application-level manager objects) are showing up in the
c_globalObjects
list. The problem seems to be relat
reveal a timing issues.
>
> Just my .02 cents,
>
>
> Feel free to share your java and js code on the dev mailbox.
>
> dirk
>
>
>
> On Sat, Feb 15, 2014 at 9:19 AM, Ichiro Furusato
> wrote:
>
> > Hi Dirk,
> >
> > Yes, you're understan
Hi Dirk,
Yes, you're understanding what I'm trying to do. In addition to the plugin
I've
also been using a bespoke JSP page with scriptlets to prototype ideas
quickly,
as well as a JavaScriptPlugin we wrote years ago as a test bed. (That could
be submitted as a replacement for the JSPWiki plugin o
ndicates that the command "blah.response" is not found.
> Maybe the JSON registerGlobalObject was not called?
> Can you put a log just before/after the registerGlobalObject() to check
> whether it gets invoked ?
>
> dirk
>
>
> On Thu, Feb 13, 2014 at 9:41 AM, Ichiro Furus
Hi Dirk,
My JSONRPCTarget is your MyJSONBlahSample. I'm quite literally doing exactly
what you suggested. Here's my registration:
JSONRPCManager.registerGlobalObject("blah",new JSONRPCTarget());
and my implementing class (i.e., an inner class, just the way it's done in
SearchManager with its
Hi Brian,
IMO, these kinds of discussions are all about aesthetics and almost always
devolve to arguments
that go nowhere, at least nowhere productive.
I know there have been a number of discussions over the many years of this
project, involving
Janne and others. Whether we love the current forma
Hi Dirk,
Well, I've now spent quite a lot of time trying to get this to work, to no
avail.
I've tried this within a plugin, then when I was unable to get that to work
I went
ahead and spot-modified a JSP to include a direct AJAX call. I was
successful
in emulating the existing search.findPages ca
o do , not clear what
> > the improvements really are -- I suggest to log an improvement ticket in
> > JIRA.
> >
> >
> > From the error message, it seems the the jsonrpc server cannot map the
> > method onto the right RPCCallable java class.
> > Which json-rpc
Hi Dirk,
Apparently the com.metaparadigm.jsonrpc code is no longer current, replaced
by
a newly-named JAbsorb package, available from Google Code:
http://code.google.com/p/jabsorb/
This looks to be written by the same author and represents a package name
change and some minor changes.
In look
Hi Dirk,
Thanks for that information. I suppose this goes back to that earlier
discussion about
jQuery vs. Mootools in a way. I've got (growing) experience with the former
and none
with the latter, and have been developing this new plugin using jQuery
since that goes
with pretty much all of the ot
e":"SearchResultIteratorTag","score":10},"javaClass":"java.util.HashMap"},{"map":{"page":"IfPlugin","score":10},"javaClass":"java.util.HashMap"},{"map":{"page":"SearchPageHelp
,"score":10},"javaClass":"java.util.HashMap"},{"map":{"page":"CSSInWikipages","score":10},"javaClass":"java.util.HashMap"},{"map":{"page":"SearchResultIteratorTag","score"
ResultIteratorTag","score":10},"javaClass":"java.util.HashMap"},{"map":{"page":"IfPlugin","score":10},"javaClass":"java.util.HashMap"},{"map":{"page":"SearchPageHelp","score&q
Hi,
I'm digging into an AJAX-related project that in theory should be using
the org.apache.wiki.rpc.json.JSONRPCManager to register the callback
used in JavaScript (i.e., via requestJSON(WikiContext)).
This obviously is working as the search popup uses it, but the existing
code seems broken. The
ctions of how to configure JSPWiki
> with Tomcat 4 or JDK 1.4, for example, don't give a positive impression.
> Further, Janne has often stated his desire to stop hosting the site, he
> has been hosting it for us just as a favor until we could get a Wiki hosted
> at Apache.
>
om-classpath-on-a-per-application-basis-in-tomcat
>
>
> http://geronimo.apache.org/GMOxDOC30/using-shared-libraries-in-your-applications.html
>
>
> https://community.jboss.org/wiki/HowToPutAnExternalFileInTheClasspath?_sscc=t
>
> Jürgen
> Am 15.01.2014 10:24 schrieb "Ich
Hi Jürgen,
I was initially confused by this as well. There is a jspwiki.properties in
the ./ini/ directory in
the war, to be customised by a jspwiki-custom.properties file either in the
Tomcat lib
directory, or in the ./WEB-INF/classes/ directory. See
https://jspwiki-wiki.apache.org/Wiki.jsp?pag
ion has been moved to the new wiki, so I thought it was time
> to start pointing the new site and filling any missing documentation as
> it's needed. Note that in any case the link to the legacy wiki is kept in
> the new page.
>
>
> br,
> juan pablo
>
>
>
> O
Hi Juan Pablo,
Not wanting to be contrary, but the 'legacy' wiki is the ecyrd.com wiki,
i.e., the wiki
prior to the Apache project. I would hope we keep a link to it as the
legacy wiki so
long as Janne keeps that site active. The 'current' documentation wiki is
the current
Apache-hosted wiki. I do
gt; >
> > > This sets the color of links inside a header to light-blue, which is
> also
> > > the color of the background.
> > >
> > > Try #searchboxMenu a { color: black; } to set the color to black.
> > >
> > >
> > > dirk
> >
>> Do a search in JSPWiki
> >> The Quick Navigation drop down now show the searched value in the
> Recent-Searches list
> >> the color of that list is white on white (in webkit)
>
>
> dirk
>
>
> On Mon, Jan 6, 2014 at 11:35 PM, Ichiro Furusato
[
https://issues.apache.org/jira/browse/JSPWIKI-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13864976#comment-13864976
]
Ichiro Furusato commented on JSPWIKI-624:
-
I'm currently working on
[
https://issues.apache.org/jira/browse/JSPWIKI-811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ichiro Furusato updated JSPWIKI-811:
Description:
Following a discussion on the dev mailing list, this is a suggestion to
Ichiro Furusato created JSPWIKI-811:
---
Summary: Migrate from Mootools to jQuery
Key: JSPWIKI-811
URL: https://issues.apache.org/jira/browse/JSPWIKI-811
Project: JSPWiki
Issue Type
ry, so we can
> track the discussion there.
>
>
> dirk
>
>
> On Mon, Jan 6, 2014 at 9:45 PM, Ichiro Furusato
> wrote:
>
> > Hi Dirk,
> >
> > Thanks for all of the information on Mootools' history and plans for
> > the future. I think the question of M
me & Safari.
>
> You may want to check-out http://lea.verou.me/demos/cssgradientsplease/ to
> convert to -webkit- gradients.
>
>
> dirk
>
>
>
> On Mon, Jan 6, 2014 at 10:41 PM, Ichiro Furusato
> wrote:
>
> > Hi Dirk,
> >
> > > I noticed some
'd like the fonts in general a little smaller
> > > * the left menu background color could be little darker, a bit more
> > > contrast would be nice (when hovering over it is exactly right).
> > >
> > >
> > > BTW: I do get 404's for the following file
JSPWiki users / developers.
>
>
>
> groet,
>
>dirk
>
>
>
>
>
> On Mon, Jan 6, 2014 at 3:50 PM, Juan Pablo Santos Rodríguez <
> juanpablo.san...@gmail.com> wrote:
>
> > Hi,
> >
> > jspwiki-commonstyles.js uses mootools, at least for some of the e
ript but when we ask them to
> make a really simple effect *without* JQuery they get all confused and
> teary-eyed.)
>
> /Janne
>
> On Jan 6, 2014, at 07:40 , Ichiro Furusato
> wrote:
>
> > Hi,
> >
> > I was just wondering what the history of the project
Hi,
I was just wondering what the history of the project's use of Mootools is,
i.e., why it's using Mootools rather than jQuery? On almost all of our own
projects (including some done for clients) we're using jQuery, and in a
plugin I'm working on right now I realised that there are conflicts with
> had a look how metadata is stored on cache)? I'm not sure if's because of
> that or is it related to other issue, have to look deeper into it
>
>
> br,
> juan pablo
>
>
>
>
> On Sun, Jan 5, 2014 at 1:18 AM, Ichiro Furusato
> wrote:
>
> > Hi,
wrote:
> Hi Ichiro,
>
> Am 04.01.2014 21:27, schrieb Ichiro Furusato:
> >
> >[{Tag Actor Person Male French }]
>
> do you have the source code for these plugins ?
>
> I'm using this Plugins in a public wiki:
> http://www.lug-kr.de (Sorry, it's on
Hi,
I just noticed that when I come back to the wiki after my session has timed
out (am not logged in but hold a cookie) I see the link to my name in the
userbox with a hilight indicating an edit link, and when I click on that
link I'm
editing my home page. If I log in the link is correctly displa
ase?
> > And what would be the advantage of tagging pages this way versus
> "tagging"
> > them with a link to Category.documentation ?
> >
> > regards,
> > Harry
> >
> >
> >
> > On 4 January 2014 14:17, Ichiro Furusato
> >
I note as the new wiki is up and running: before everyone goes through and
adds all the category
links, is there any desire to instead use the TagPlugin we have as part of
the Neocortext Wiki
Plugins? This provides a means of tagging pages, with querying on tags
available via the
HasTagOf plugin. T
he following files with this skin :
> /wiki/templates/default/images/jspwiki-strip.gif
> /wiki/templates/default/skins/CleanBlue/images/search.gif
> /wiki/templates/default/skins/CleanBlue/images/sortable.gif
>
> regards,
> Harry
>
>
>
>
> On 2 January 2014 02:11, Ich
rast would be nice (when hovering over it is exactly right).
>
>
> BTW: I do get 404's for the following files with this skin :
> /wiki/templates/default/images/jspwiki-strip.gif
> /wiki/templates/default/skins/CleanBlue/images/search.gif
> /wiki/templates/default/skins/Cle
nto
> trunk on r1486481, but no clues on how, when or why got in there in the
> first place. Maybe to get CommandResolverTest.testSpecialPageReference
> running, but again that's weird b/c that special page reference is set on
> src/test/resources/jspwiki-custom.properties
>
> Anyway, I&#x
Happy new year Harry and thanks for the new wiki. Good timing on a new
start...
Would you be interested in adopting a template we've been testing here for
about a month? It's not perfect but it looks a lot better than the default,
and
we'd be willing to donate it to the project under an Apache lic
Hi,
I'm in a bit of a bind. I've just installed a build from a recent SVN
version (which shows up
as "JSPWiki v2.10.0-svn-61 ") and noticed that the sidebar link to the
RecentChanges page
links to the home page, i.e., the link seems to not work. I thought this
might be due to some
problem in the J
module under version control.
>
>
> hth,
> juan pablo
>
>
> On Mon, Dec 23, 2013 at 1:21 PM, Glen Mazza wrote:
>
> > On 12/23/2013 03:51 AM, Ichiro Furusato wrote:
> >
> >> I just realised (after re-reading this away from my office) that you
> >> di
file there (actually, just need to rename your
> jspwiki.properties override to this new name), but the new design allows
> you to leave the WAR alone by using the Tomcat "lib" folder instead, and
> you can keep updating/replacing the WAR without needing to re-insert your
> c
his new name), but the new design allows
> you to leave the WAR alone by using the Tomcat "lib" folder instead, and
> you can keep updating/replacing the WAR without needing to re-insert your
> custom file each time.
>
> Glen
>
> On 12/22/2013 04:42 AM, Ichiro Furusat
Hi,
Just a note regarding my experience installing the new version, which might
be pilot error.
I don't get a vote but this experience might suggest a problem with the
release, dunno.
After building the war I moved its content to my tomcat webapps directory
but found from
the error logs that JSPW
Just a note: when I tried to access the source zip permissions didn't
permit me to download it.
On Sat, Dec 21, 2013 at 12:02 PM, Juan Pablo Santos Rodríguez <
juanpablo.san...@gmail.com> wrote:
> This is a release vote for Apache JSPWiki, version 2.10.0. The vote will be
> open for at least 72
Juan Pablo,
I'm sure your dedication is much appreciated by many. While I
don't have a vote any move to 2.10.0 would get a +1 from me.
In terms of the upcoming vote, I thought to add that as an added
incentive, once JSPWiki 2.10.0 stabilises, we hope to release a
WikiProvider implementation calle
se-wise, the project has my permission
to use this code (under the existing Apache license) in Apache JSPWiki.
Sorry I haven't had more time to
devote to finishing this...
Ichiro
On Tue, Dec 10, 2013 at 1:40 PM, Ichiro Furusato
wrote:
> Actually, kinda both. I'll zip up everything I
antos Rodríguez <
juanpablo.san...@gmail.com> wrote:
> Hi Ichiro,
>
> the EntityManager or the interface extraction? In any case, yes please,
> would you mind uploading it as an attachment to JSPWIKI-155?
>
> thanks!
>
>
> br,
> juan pablo
>
>
> On Mon, Dec 9, 2
Hi Juan Pablo,
Since I've kinda already done most of this would you like me to send you
what I've got?
It might be a good starting point and I wouldn't feel like I've wasted that
effort...
Ichiro
On Thu, Dec 5, 2013 at 11:49 AM, Juan Pablo Santos Rodríguez (JIRA) <
j...@apache.org> wrote:
>
>
Not all use cases of JSPWiki involve a container, e.g., we have used it as
an embedded application in several instances, and are also using it running
from a simple Jetty started up from a POM. So removing the caching
functionality from within the application would remove it completely as a
feature
> > 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 th
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
wrote:
> Hi,
>
> I'm in the middle of working through some
Hi,
I don't have the time right now to dig into what you guys are proposing
with wro4j so I
can only add a cautionary tale to the table. I imagine that the vast
majority of JSPWiki
users (i.e., installers) will be modifying the PlainVanilla theme to create
a style that
matches their individual req
Hi Glen,
I'm in favour of simplifying the property management of JSPWiki. The
default_jspwiki.properties file is indeed unused (so far as I know).
Projects tend to get more complicated over time rather than the converse,
so if you think this is a substantial improvement and simplifies things
then
013 at 11:48 PM, Glen Mazza wrote:
>
> > I put that item in because JP had requested it. JP +1'ed Style C/Sun
> > indentation, which makes you and me happy, so I'll happily give him his
> > logging preference of choice, as long as it's a competent solution, an
I've followed this debate for years now and it's hard to really justify (to
my mind at least)
not simply going with Log4j. It's all but a standard. I've used the JDK's
logging facility
and SLF4J and there simply is no added benefit to a facade API. The only
real justification
would be a project whe
r these; I'll expect to
> begin next week, creating an api module with a few classes, an utils
> module, again with a few classes and a filter module, holding all
> WikiFilters related stuff
>
>
> br,
> juan pablo
>
> On Thu, Jul 11, 2013 at 11:35 AM, Ichiro Furusato <
75 matches
Mail list logo
