[jira] [Commented] (JSPWIKI-873) AttachmentManager#getAllAttachments() does not return more than exactly 1000 attachments
[ https://issues.apache.org/jira/browse/JSPWIKI-873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14227674#comment-14227674 ] Glen Mazza commented on JSPWIKI-873: Is this limit per-page (in which case 1000 seems more than reasonable), or for the JSPWiki running instance as a whole (perhaps upping to 3000-5000 would be preferable then.) I don't see much reason to spend time coding JSPWiki to support an infinite number of attachments at a cost of other work getting done, since 3000 will cover 98% of our possible audience anyway. AttachmentManager#getAllAttachments() does not return more than exactly 1000 attachments Key: JSPWIKI-873 URL: https://issues.apache.org/jira/browse/JSPWIKI-873 Project: JSPWiki Issue Type: Bug Components: Core storage Affects Versions: 2.10.2 Reporter: Albrecht Striffler Labels: attachments I'm not sure if this is only a problem in 2.10.2 (svn-head) or also in the released 2.10.1... As already stated in the summary/title, the AttachmentManager does not return more than 1000 attachments using the method getAllAttachments(). This is obviously very problematic, if JSPWiki is used at the api level and has more than 1000 attachments... My guess is, that it has to do with the CachingAttachmentProviders Cache size of 1000. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JSPWIKI-870) JSPWiki does not start, if tomcat directory path contains a white space
[ https://issues.apache.org/jira/browse/JSPWIKI-870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14195640#comment-14195640 ] Glen Mazza commented on JSPWIKI-870: Albrecht, why would you put a space in your location for Tomcat? That usually brings up lots of headaches with WARs, not just JSPWiki... JSPWiki does not start, if tomcat directory path contains a white space --- Key: JSPWIKI-870 URL: https://issues.apache.org/jira/browse/JSPWIKI-870 Project: JSPWiki Issue Type: Bug Components: Authentication Authorization Affects Versions: 2.10.1 Environment: Bug found on a mac, but is probably platform independent. Reporter: Albrecht Striffler Priority: Critical Labels: decode, policy As described, JSPWiki does not start if run from a directory containing a white space in its path. The problem is, that the policy file is not found/accepted. The jspwiki.log contains the following stack trace: org.apache.wiki.api.exceptions.WikiException: JSPWiki: Unable to load and setup properties from jspwiki.properties. Failed to start managers: File /Programme/tomcat%20test/webapps/JSPWiki/WEB-INF/jspwiki.policy does not exist, or the SecurityManager prohibited access to it. at org.apache.wiki.WikiEngine.init(WikiEngine.java:440) at org.apache.wiki.WikiEngine.getInstance(WikiEngine.java:370) at org.apache.wiki.ui.WikiServletFilter.init(WikiServletFilter.java:82) at org.apache.catalina.core.ApplicationFilterConfig.initFilter(ApplicationFilterConfig.java:279) .. As you can imagine, the problem is the %20 in tomcat%20test. The security manager will check if this file exists, but because of the %20, does not find anything. Of course, the correct file path would be /Programme/tomcat test/webapps/JSPWiki/WEB-INF/jspwiki.policy. I debugged a little bit and think a fix could be very easy: In the AuthorizationManager, the policyFile is instantiated in line 499 using File policyFile = new File( policyURL.getPath() ); The URL contains the encoded white space and getPath() unfortunately does not decode. Either the returned path is decoded manually or the URL is transformed into a URI (using toURI()) and then getPath() is called on the URI which returns a decoded path. Since this bug was not present in JSPWiki 2.8.x, I guess this URL was an URI in the past... Help very much appreciated, this is currently pretty much a blocker for us... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JSPWIKI-205) Obfuscate on disk content type
[ https://issues.apache.org/jira/browse/JSPWIKI-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14161748#comment-14161748 ] Glen Mazza commented on JSPWIKI-205: I don't know enough about encryption to know how degraded encryption would be with a hardcoded salt value but that looks like a code smell to be hardcoding it. I would prefer a stop-the-presses, halt JSPWiki exception if you try to activate encryption without properly setting the salt value or other secure/sensitive values such as passwords. Someone who doesn't know how to create a correct salt value has no business trying to activate the JSPWiki encryption. We can someday document on our Wiki how to create salt values (preferably link to some other place that explains it well), but until then the dev needs to know his stuff. What you call the administrator is frequently just a programming grunt who only cares about reporting back to his technically clueless manager that the pages are encrypted. It's perhaps usually not the grunt's data that is being compromised (so he is less concerned), but possibly yours or my data, so JSPWiki should have some built-in safeguards to protect against lazy developers compromising other people's data due to haphazard encryption configuration. On the other hand, what if the developer puts in a 0 or a 1 for the salt value, or some similar value that makes (?) encryption meaningless? If you know enough about the proper structure of salt values, a further sanity check that the salt value is something usable--say minimum length--might be nice to add. By the way, thanks for your work so far on this project. Obfuscate on disk content type -- Key: JSPWIKI-205 URL: https://issues.apache.org/jira/browse/JSPWIKI-205 Project: JSPWiki Issue Type: Improvement Components: Core storage Reporter: Chris Lialios Priority: Trivial Attachments: BasicOverview.doc, EncryptingProviderSource.zip, encryption.patch, encryption.patch, encryption.patch, encryption.patch We would like to store passwords within the wiki pages. Securing the page is trivial, however the contents on disk remain clear text. It would be very nice to have a page type that could be stored in an obfuscated form on disk. As an addition have a secondary password to display/edit the encrypted contents on disk for those who do not want to use wiki security on the page. I suspect this will have potentially drastic effects on the revisions process, but it would be a small price to pay for security. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JSPWIKI-835) better mobile experience
[ https://issues.apache.org/jira/browse/JSPWIKI-835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14140450#comment-14140450 ] Glen Mazza commented on JSPWIKI-835: For our small project, it would probably be better for JSPWiki to have a responsive theme (similar to those used by Bootstrap, Foundation, etc.) that will work reasonably well on each type of device, while still making sure it looks best for those using regular monitors or tablets, JSPWiki's primary use case. Device detection is a very messy art and if we went that route I believe it would engender countless JIRAs whenever we get it wrong for a particular device, which would be often, bringing down the project in the process. better mobile experience Key: JSPWIKI-835 URL: https://issues.apache.org/jira/browse/JSPWIKI-835 Project: JSPWiki Issue Type: Improvement Components: Default template Affects Versions: 2.10 Reporter: Jürgen Weber Attachments: Screenshot_2014-03-26-22-55-48.png, Screenshot_2014-03-26-23-07-11.png Currently JSPWiki is not optimized for mobile devices, it looks the same on mobile as on desktop, with the effect, that the left menu and the tabs on top of the page look very small. JSPWiki should automatically recognise that it is accessed from a mobile device and format its output for mobile. see http://mail-archives.apache.org/mod_mbox/jspwiki-dev/201403.mbox/browser -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JSPWIKI-865) Provide the source page on the Edit.jsp link
[ https://issues.apache.org/jira/browse/JSPWIKI-865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14130810#comment-14130810 ] Glen Mazza commented on JSPWIKI-865: I'm not sure what it matters (who cares) from what page a new page was spawned. AFAICT Wikipedia does not report on that information--does anyone really care today whether it was the article on Ontario or on Canada that originally engendered the article on Toronto umpteen years back? Sometimes the motivations of the Wiki maintainer in writing from A to B can be embarrassing for the Wiki maintainer or implicitly defamatory for B, not something the maintainer would want broadcasted with a source/parent listing. This additional information would also create more maintenance headaches. I create ten articles on cities from New Jersey, I would want it shown that their parent article was New Jersey. But if I accidentally created an article on a New Jersey city from the Pennsylvania page, even if I updated the pages the parent of that page will still be Pennsylvania, which would look bad on Wiki pages, hence JIRA requests to allow people to change the source/parent of a page so it would show New Jersey, defeating your apparent meaning of source/parent. Ultimately, wiki pages don't really have a hierarchy (even if a wiki is internally implemented using one), all pages are of equal importance and unrelated to each other except for whatever links they have between the two. Storage of a source/parent field would incorrectly imply a hierarchy. Provide the source page on the Edit.jsp link Key: JSPWIKI-865 URL: https://issues.apache.org/jira/browse/JSPWIKI-865 Project: JSPWiki Issue Type: Wish Components: Core storage Reporter: David Vittor When a new page is linked to from an existing page, e.g. [NewPage] The code creates a link like this: * https://jspwiki-wiki.apache.org/Edit.jsp?page=NewPage I think it might be a good idea to include the original source page, like: * https://jspwiki-wiki.apache.org/Edit.jsp?page=NewPagesrc=CurrentPage Maybe these should be POST requests, but I think we should maybe go incrementally. I think it would be great for creating / storing the heirarchy of pages. Any thoughts? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JSPWIKI-811) Migrate from Mootools to jQuery
[ https://issues.apache.org/jira/browse/JSPWIKI-811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14124465#comment-14124465 ] Glen Mazza commented on JSPWIKI-811: On Apache Roller, we don't put JS or JS libraries in a common header file, we just include them in each JSP that needs them. That way, JSPs that don't need those libraries aren't burdened with downloading them, and also it allows us to update each file with different JS libraries file-by-file instead of being required to do it all at once. Therefore, I suspect it would be better to pull out mootools jspwiki-common (MJC) from commonheader.jsp and instead manually place it in each of the 13-15 files using it. Those files which are using MJC in very few places can be the first to be converted to JQuery (i.e., have their references to MJC removed), then go file by file until the need for MJC is gone. (As for JC, hopefully it can be made library-independent and also reduced in size as we rely on standard libraries like JQuery for its functionality.) Migrate from Mootools to jQuery --- Key: JSPWIKI-811 URL: https://issues.apache.org/jira/browse/JSPWIKI-811 Project: JSPWiki Issue Type: Improvement Components: Default template Reporter: Ichiro Furusato Labels: javascript Fix For: FutureVersion Following a discussion on the dev mailing list, this is a suggestion to migrate from Mootools to jQuery, given the latter's overwhelming popularity. Re: Mootools vs. jQuery, jspwiki-dev mailing list http://mail-archives.apache.org/mod_mbox/jspwiki-dev/201401.mbox/%3CCAEUnRMtqhu%3Drd5MfJ4mEJdDKn2bhMZkFKwMKogYyjfh%3D-j9ocA%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JSPWIKI-864) ValidationManager added to WikiEngine
[
https://issues.apache.org/jira/browse/JSPWIKI-864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14113619#comment-14113619
]
Glen Mazza commented on JSPWIKI-864:
Could we use this: http://commons.apache.org/proper/commons-validator/ ? I
wouldn't want us to be reinventing the wheel if we can avoid it.
ValidationManager added to WikiEngine
-
Key: JSPWIKI-864
URL: https://issues.apache.org/jira/browse/JSPWIKI-864
Project: JSPWiki
Issue Type: Wish
Components: Core storage
Reporter: David Vittor
Priority: Minor
Here is another idea. When I write plugins, I spend a lot of time writing
code to make sure that the parameters passed into the plugins are valid.
Things such as strings, booleans, numbers, urls, emails addresses, etc.
I was thinking if we could create a ValidationManager class that could take a
List of Validators (interface) and pass values for validation.
The two main interface method of a Validator would be:
* void validate(String value, String type) throws InvalidValueException;
* void validate(String value, String type, boolean required) throws
InvalidValueException;
** Note: by default required would be false.
The type would be a static int TYPE_EMAIL, TYPE_STRING, etc. defined in the
ValidationManager.
The ValidationManager, would have property:
* ListValidator validators;
and methods:
* void addValidator(Validator v);
* Validator removeValidator(Validator v);
* List Validator getValidators();
This would be very beneficial for all plugin developers, cause then they can
call:
*
wikiContent.getValidationManager().validate(params.get('url'),ValidationManager.TYPE_URL);
And they don't need a try catch, as the user will be told exactly what the
error was. If all parameters are valid, the plugin can continue to do it's
work.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (JSPWIKI-212) transport-guarantee CONFIDENTIAL should be removed from web.xml
[ https://issues.apache.org/jira/browse/JSPWIKI-212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14009551#comment-14009551 ] Glen Mazza commented on JSPWIKI-212: Oh, now I remember, there is a difference between Roller and JSPWiki CMA. Roller's configuration is really just for SSL, it doesn't use any usernames and passwords in the tomcat-users.xml file, that stuff is still stored in Roller's database (MySQL or Derby or whatever). A compromised username/password would just affect the Roller web application. JSPWiki, however, *would* use the usernames and passwords in the tomcat-users for its CMA, if that information were compromised an attacker could get control of the Tomcat servlet container if the usernames and passwords were configured poorly enough. (E.g., users were lazily given Tomcat manager roles). I would think by default this should be encrypted via SSL so the data in the tomcat-users.xml never gets compromised. A newbie user (or one who hasn't much time to research secure installations) isn't going to be using Tomcat CMA but the default userdatabase and groupdatabase.xml approach. So we already have a nice simple OOTB solution that doesn't require much effort. I would think though that if one wishes to graduate onto Tomcat CMA that the SSL should be activated by default. If this is causing a user too much heartache (he can't understand how to deactivate it or is uncertain how to activate SSL in his servlet container) at that stage it would be good for the user to study up on SSL or retreat back to the simpler userdatabase/groupdatabase approach. transport-guarantee CONFIDENTIAL should be removed from web.xml --- Key: JSPWIKI-212 URL: https://issues.apache.org/jira/browse/JSPWIKI-212 Project: JSPWiki Issue Type: Improvement Components: Authentication Authorization Affects Versions: 2.6.2 Environment: apache-tomcat-6.0.16 Reporter: Jürgen Weber Assignee: Andrew Jaquith Priority: Minor The default web.xml of JSPWiki contains two times user-data-constraint transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint for container managed authorization. But by default Tomcat has not switched on SSL, and trying to log in to JSPWiki you get Firefox can't establish a connection to the server at localhost:8443. By default the user-data-constraint element should be removed as it makes activating container managed authorization unnecessarily difficult. Especially as it is not easy or obvious to notice the connection between the cited error message and the user-data-constraint element. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (JSPWIKI-842) deliver a template for jspwiki-custom.properties
[ https://issues.apache.org/jira/browse/JSPWIKI-842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Glen Mazza closed JSPWIKI-842. -- Resolution: Fixed More documentation added on jspwiki-custom.properties. deliver a template for jspwiki-custom.properties Key: JSPWIKI-842 URL: https://issues.apache.org/jira/browse/JSPWIKI-842 Project: JSPWiki Issue Type: Improvement Components: Core storage Affects Versions: 2.10 Reporter: Jürgen Weber In the delivered jspwiki.war there should be a jspwiki-custom.properties.template in WEB-INF to get people started with a jspwiki-custom.properties It should be well documented which would make it a copy of the old jspwiki.properties .. I think starting from an existing properties file is easier than picking the values from https://jspwiki-wiki.apache.org/Wiki.jsp?page=Configuration especially for people doing Advanced Installation. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (JSPWIKI-212) transport-guarantee CONFIDENTIAL should be removed from web.xml
[ https://issues.apache.org/jira/browse/JSPWIKI-212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14009013#comment-14009013 ] Glen Mazza commented on JSPWIKI-212: Oh, now I see. OK, I don't care either way. transport-guarantee CONFIDENTIAL should be removed from web.xml --- Key: JSPWIKI-212 URL: https://issues.apache.org/jira/browse/JSPWIKI-212 Project: JSPWiki Issue Type: Improvement Components: Authentication Authorization Affects Versions: 2.6.2 Environment: apache-tomcat-6.0.16 Reporter: Jürgen Weber Assignee: Andrew Jaquith Priority: Minor The default web.xml of JSPWiki contains two times user-data-constraint transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint for container managed authorization. But by default Tomcat has not switched on SSL, and trying to log in to JSPWiki you get Firefox can't establish a connection to the server at localhost:8443. By default the user-data-constraint element should be removed as it makes activating container managed authorization unnecessarily difficult. Especially as it is not easy or obvious to notice the connection between the cited error message and the user-data-constraint element. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (JSPWIKI-838) WEB-INF\jspwiki.policy does not exist, or the SecurityManager prohibited access to it.
[ https://issues.apache.org/jira/browse/JSPWIKI-838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Glen Mazza closed JSPWIKI-838. -- Resolution: Incomplete Please ask support questions on the JSPWiki User's mailing list. When doing that, let us know whether your JSPWiki installation has the jspwiki.policy file that the error message is claiming is missing, or if it's a security manager issue. WEB-INF\jspwiki.policy does not exist, or the SecurityManager prohibited access to it. -- Key: JSPWIKI-838 URL: https://issues.apache.org/jira/browse/JSPWIKI-838 Project: JSPWiki Issue Type: Bug Components: Default template Affects Versions: 2.10 Environment: Windows 8.1 Apache Tomcat/7.0.53 Java SE Development Kit 8 Update 5 (64 bit) JSPWiki.war 2.10.0 Reporter: Tony Johnson Labels: 2.10.0, war Fix For: 2.10 When trying to deploy the JSPWiki.war file the following exceptions occur 2014-05-13 14:49:41,351 [localhost-startStop-1] INFO org.apache.wiki.auth.AuthorizationManager - We found security policy URL: file:/C:/Program%20Files/Apache%20Software%20Foundation/Tomcat%207.0/webapps/WDSWiki/WEB-INF/jspwiki.policy and transformed it to file C:\Program%20Files\Apache%20Software%20Foundation\Tomcat%207.0\webapps\WDSWiki\WEB-INF\jspwiki.policy 2014-05-13 14:49:41,351 [localhost-startStop-1] FATAL org.apache.wiki.WikiEngine - Failed to start managers. java.lang.IllegalArgumentException: File C:\Program%20Files\Apache%20Software%20Foundation\Tomcat%207.0\webapps\WDSWiki\WEB-INF\jspwiki.policy does not exist, or the SecurityManager prohibited access to it. at org.freshcookies.security.policy.PolicyReader.init(PolicyReader.java:188) at org.freshcookies.security.policy.LocalPolicy.refresh(LocalPolicy.java:324) at org.apache.wiki.auth.AuthorizationManager.initialize(AuthorizationManager.java:502) at org.apache.wiki.WikiEngine.initialize(WikiEngine.java:586) at org.apache.wiki.WikiEngine.init(WikiEngine.java:430) at org.apache.wiki.WikiEngine.getInstance(WikiEngine.java:370) at org.apache.wiki.ui.WikiServletFilter.init(WikiServletFilter.java:82) at org.apache.catalina.core.ApplicationFilterConfig.initFilter(ApplicationFilterConfig.java:279) at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:260) at org.apache.catalina.core.ApplicationFilterConfig.init(ApplicationFilterConfig.java:105) at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:4809) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5485) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632) at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:1073) at org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1857) at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) 2014-05-13 14:49:41,366 [localhost-startStop-1] ERROR org.apache.wiki.WikiEngine - ERROR: Failed to create a Wiki engine, stacktrace follows org.apache.wiki.api.exceptions.WikiException: JSPWiki: Unable to load and setup properties from jspwiki.properties. Failed to start managers: File C:\Program%20Files\Apache%20Software%20Foundation\Tomcat%207.0\webapps\WDSWiki\WEB-INF\jspwiki.policy does not exist, or the SecurityManager prohibited access to it. at org.apache.wiki.WikiEngine.init(WikiEngine.java:440) at org.apache.wiki.WikiEngine.getInstance(WikiEngine.java:370) at org.apache.wiki.ui.WikiServletFilter.init(WikiServletFilter.java:82) at org.apache.catalina.core.ApplicationFilterConfig.initFilter(ApplicationFilterConfig.java:279) at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:260) at org.apache.catalina.core.ApplicationFilterConfig.init(ApplicationFilterConfig.java:105) at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:4809) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5485) at
[jira] [Commented] (JSPWIKI-811) Migrate from Mootools to jQuery
[ https://issues.apache.org/jira/browse/JSPWIKI-811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13863845#comment-13863845 ] Glen Mazza commented on JSPWIKI-811: Kono ii suggestion o arigatou, Ichiro. :) I would like JSPWiki to make this switch, it's easier to attract committers when we're using the latest and greatest technologies. Migrate from Mootools to jQuery --- Key: JSPWIKI-811 URL: https://issues.apache.org/jira/browse/JSPWIKI-811 Project: JSPWiki Issue Type: Improvement Components: Default template Reporter: Ichiro Furusato Labels: javascript Fix For: FutureVersion Following a discussion on the dev mailing list, this is a suggestion to migrate from Mootools to jQuery, given the latter's overwhelming popularity. Re: Mootools vs. jQuery, jspwiki-dev mailing list http://mail-archives.apache.org/mod_mbox/jspwiki-dev/201401.mbox/%3CCAEUnRMtqhu%3Drd5MfJ4mEJdDKn2bhMZkFKwMKogYyjfh%3D-j9ocA%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (JSPWIKI-792) Replace OpenSymphony's oscache with ehcache
[ https://issues.apache.org/jira/browse/JSPWIKI-792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13755768#comment-13755768 ] Glen Mazza commented on JSPWIKI-792: Hi Harry, apparently up to 2.6.6 they called it net.sf.ehcache:ehcache-core (https://oss.sonatype.org/content/repositories/sourceforge-releases/net/sf/ehcache/ehcache-core/, of which Apache Shiro uses 2.5.3 today), then starting with 2.7.0 used artifactId of ehcache instead of ehcache-core: http://forums.terracotta.org/forums/posts/list/8076.page. 2.7.0+'s ehcache-core is now internal only, according to the latter pom's description field: http://repo1.maven.org/maven2/net/sf/ehcache/internal/ehcache-core/2.7.2/ehcache-core-2.7.2.pom. My suggestion (and it's only that), I would stay legit and use ehcache even though it's big at 6.7MB. ehcache implements javax.cache (http://gregluck.com/blog/archives/2011/10/javax-cache-the-new-java-caching-standard/), something other companies in the future might implement, allowing us to switch implementations to hopefully a smaller one. We can use anything Apache-license compatible (LGPL we can't use). Spring and Google Guice apparently have alternatives already: http://722.kalaari.net/b/lang/en/2011/12/23/jsr107-javax-cache-annotations-with-google-guice/. I was earlier trying to get Google Guice out of Apache Roller and let it be 100% Spring (as we use Spring security there anyway), but Guice might be quite good for lighter-weight JSPWiki (where Spring would be overkill). Replace OpenSymphony's oscache with ehcache --- Key: JSPWIKI-792 URL: https://issues.apache.org/jira/browse/JSPWIKI-792 Project: JSPWiki Issue Type: Improvement Reporter: Glen Mazza Assignee: Harry Metske Attachments: JSPWIKI-792.patch OpenSymphony website is dead, ehcache seems common today. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JSPWIKI-796) UserPreferences is broken
[
https://issues.apache.org/jira/browse/JSPWIKI-796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13728874#comment-13728874
]
Glen Mazza commented on JSPWIKI-796:
@ Harry, I think the decision to drop support for Tomcat 5 should not be made
by us but by the Tomcat team, which they explicitly did last year
(http://tomcat.apache.org/tomcat-55-eol.html). Note Dirk wants support not
only for Tomcat 5.5 but also Tomcat 5.0, which the Tomcat team last patched in
October 2007 (http://svn.apache.org/viewvc/tomcat/archive/tc5.0.x/tags/). Even
the build.xml we were Mavenizing was using Tomcat 5.5 for precompilation. At
this time, I think the burden is on Dirk for him to first veto the change on
the Dev mailing list and provide valid reasons--oh, we didn't have a vote on
that JSTL version upgrade--alone is not a legitimate reason (where was our
vote on Dirk's change to wro4j?), as we operate on lazy consensus. After his
veto, then we can have a vote.
@ Dirk, that JSTL upgrade was made 3-4 months ago and nobody, including
yourself, complained about it. Part of the problem was that you weren't active
on the team at the time and bothering to look at the commits. Those who were
didn't mind the change. You can't go sleep on the project for six months and
then demand votes on everything that occurred you didn't like while you were
inactive. Use your veto pen instead.
As for Unless I missed some updates to that -- the JSPWiki site is read-only
(read the top of the page), it's frozen, that's why there's no updates to it.
What you missed were the commits that you failed to veto several months ago.
While some people like Harry turned out to still have write access to it
(something I didn't know at the time), other team members like myself don't, so
it cannot be considered a definitive site. As write access to that site is not
automatic based on team membership but a function of Janne's decisions (it's
fully within his rights to say no and I earlier made clear my desire to
update it...), it can't be definitive for JSPWiki.
UserPreferences is broken
-
Key: JSPWIKI-796
URL: https://issues.apache.org/jira/browse/JSPWIKI-796
Project: JSPWiki
Issue Type: Bug
Components: Default template
Affects Versions: 2.10
Reporter: brushed
Assignee: Glen Mazza
(detected on v2.10.0-svn-22)
The new JSTL version, upgraded to version 1.2 since the MAVEN update, is
giving problems in resolving certain EL expressions.
EG, the UserPreference page is throwing an error when evaluating a forEach
loop.
{noformat}
java.lang.NoClassDefFoundError: javax/el/ValueExpression
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2475)
at java.lang.Class.privateGetPublicMethods(Class.java:2595)
at java.lang.Class.getMethods(Class.java:1437)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JSPWIKI-796) UserPreferences is broken
[
https://issues.apache.org/jira/browse/JSPWIKI-796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13728495#comment-13728495
]
Glen Mazza commented on JSPWIKI-796:
Hi Dirk. I can't replicate this issue (this is the page where we choose our
language, skin, time zone, etc., right?) I run the app via mvn
tomcat7:run-war from the jspwiki-war folder or alternatively by installing on
a Tomcat 7 standalone server. All changes within User preferences are working
fine.
How are you deploying JSPWiki -- on what servlet container (embedded?
standalone?) and what JDK? What steps are you running on the UserPreferences
page for this issue to occur.
Note the TestContainer is relying on an older Jetty 7.x plugin (upgrading it to
9.x right now brings compilation problems ATM), I don't know if that's the
issue.
UserPreferences is broken
-
Key: JSPWIKI-796
URL: https://issues.apache.org/jira/browse/JSPWIKI-796
Project: JSPWiki
Issue Type: Bug
Components: Default template
Affects Versions: 2.10
Reporter: brushed
Assignee: Glen Mazza
(detected on v2.10.0-svn-22)
The new JSTL version, upgraded to version 1.2 since the MAVEN update, is
giving problems in resolving certain EL expressions.
EG, the UserPreference page is throwing an error when evaluating a forEach
loop.
{noformat}
java.lang.NoClassDefFoundError: javax/el/ValueExpression
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2475)
at java.lang.Class.privateGetPublicMethods(Class.java:2595)
at java.lang.Class.getMethods(Class.java:1437)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JSPWIKI-796) UserPreferences is broken
[
https://issues.apache.org/jira/browse/JSPWIKI-796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13728548#comment-13728548
]
Glen Mazza commented on JSPWIKI-796:
Dirk, that you were using Tomcat 5 is quite pertinent information you should
have stated in this bug report. I upped us a few months back to Servlet 2.5
(Tomcat 6) and removed the Tomcat 5 crud in our old Ant build.xml. The
JSPWiki site you referenced is not the official source of information for the
Apache JSPWiki project, it was largely last updated in 2007 and we have no
control over its text--while Janne may opt to give some JSPWiki team members
write access to it (I don't have it, although I haven't asked) write access to
that site is not an automatic function of being a JSPWiki team member, and so
it remains unofficial until it's moved over to Apache and all team members can
update it.
Tomcat 5 is dead and unsupported, even by the Tomcat team -- it's not even on
their website today: http://tomcat.apache.org/. As it's unsupported, you
cannot base a secure solution on it today. Minimum is Tomcat 6.
More importantly, we cannot attract committers when we tell them they have to
work with obsolete products like Tomcat 5, we can, should and will lose them
instead to other projects that allow them to develop modern skills they can use
in their careers. It's difficult enough trying to compete with the Hadoops and
Cloudstacks for committers without us further requiring volunteers to work with
Tomcat 5. For the open source model to work, *both* the volunteer developers
and the users have to benefit, and committers just don't benefit working with
that product today. If you disagree, feel free to move the discussion over to
the dev list.
UserPreferences is broken
-
Key: JSPWIKI-796
URL: https://issues.apache.org/jira/browse/JSPWIKI-796
Project: JSPWiki
Issue Type: Bug
Components: Default template
Affects Versions: 2.10
Reporter: brushed
Assignee: Glen Mazza
(detected on v2.10.0-svn-22)
The new JSTL version, upgraded to version 1.2 since the MAVEN update, is
giving problems in resolving certain EL expressions.
EG, the UserPreference page is throwing an error when evaluating a forEach
loop.
{noformat}
java.lang.NoClassDefFoundError: javax/el/ValueExpression
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2475)
at java.lang.Class.privateGetPublicMethods(Class.java:2595)
at java.lang.Class.getMethods(Class.java:1437)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
