jamwiki-devel Mailing List for JAMWiki (Page 2)
Brought to you by:
wrh2
Menu
▾
▴
jamwiki-devel — JAMWiki development mailing list.
This list is closed, nobody may subscribe to it.
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(5) |
Dec
(45) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2011 |
Jan
(53) |
Feb
(23) |
Mar
(6) |
Apr
(2) |
May
(5) |
Jun
(1) |
Jul
(2) |
Aug
(2) |
Sep
(1) |
Oct
|
Nov
|
Dec
(1) |
| 2012 |
Jan
(7) |
Feb
(2) |
Mar
(1) |
Apr
|
May
(7) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
(1) |
Feb
(5) |
Mar
(54) |
Apr
(7) |
May
(1) |
Jun
|
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Ryan H. <rya...@gm...> - 2013-03-26 04:41:32
|
As Thomas noted, Sourceforge has been nagging me for some time to upgrade the JAMWiki project on the Sourceforge site. That is done now, details are below: -------- Original Message -------- Subject: SourceForge Project Upgrade - Code Repo Complete Date: Tue, 26 Mar 2013 04:37:35 +0000 From: SourceForge.net <nor...@in...> Reply-To: no...@in... To: no...@in... Your code repository in upgraded project jamwiki is now ready for use. Old repository url: git://jamwiki.git.sourceforge.net/gitroot/jamwiki/jamwiki New repository checkout command: git clone ssh://USE...@gi.../p/jamwiki/code jamwiki-code You should do a checkout using the new repository location. The old repository is read-only now. For more detailed instructions on migrating to your new repo, please see https://sourceforge.net/p/forge/community-docs/Repository%20Upgrade%20FAQ/ |
|
From: Peter P. <pit...@us...> - 2013-03-25 07:44:44
|
Hey Thomas, Am 24.03.2013 um 20:57 schrieb Thomas Koch <th...@ko...>: > I have pushed master and all tags now. Thanks! > @Peter: Could you update the SCM data in the pom.xml? Did so, but I saw no commit message on jamwiki-commit. I've never managed a SF project, but I could imagine, there's a (post-)commit hook in old SVN repository, that need to be translated into a post-receive hook like https://github.com/git/git/blob/master/contrib/hooks/post-receive-email to send the mail to jamwiki-commit list. > We can browse the wiki together and update the links there. We'll do :-) -- Regards, Peter |
|
From: Thomas K. <th...@ko...> - 2013-03-24 19:57:27
|
Hi Ryan, Peter, I have pushed master and all tags now. @Peter: Could you update the SCM data in the pom.xml? We can browse the wiki together and update the links there. @Ryan: Sourceforge asks projects to upgrade to their new plattform. No need to hurry, just want to know that you're aware of it. Regards, Thomas Koch, http://www.koch.ro |
|
From: Thomas K. <th...@ko...> - 2013-03-24 17:31:59
|
Ryan Holliday: > Hi Thomas, Peter, > > I've enabled Git on Sourceforge and provided Git access to all JAMWiki > developers, but haven't yet imported anything. Hi Ryan, I don't have the right to push. It seems that you need to grant me developer status on the jamwiki sourceforge project. I'll only push the master branch and all tags to sourceforge for now. We can at any time also pull the other branches from github and push them to sourceforge if we want to keep them and enlarge the repository size. Regards, Thomas Koch, http://www.koch.ro |
|
From: Ryan H. <rya...@gm...> - 2013-03-24 17:00:55
|
Hi Thomas, Peter, I've enabled Git on Sourceforge and provided Git access to all JAMWiki developers, but haven't yet imported anything. Instructions for doing so can be found at https://sourceforge.net/apps/trac/sourceforge/wiki/Git Would either of you be willing to do the initial import? It should be extremely straightforward, but as a relative Git newbie I figured it would be best to leave it to the experts. Once that's done I'll look into changing SVN to be read-only to avoid any issues with code accidentally getting committed to the wrong place. Ryan On 3/21/2013 11:35 PM, Thomas Koch wrote: > Hi Ryan, > > the release branches and tags are available. I propose that you enable a Git > repo on sourceforge and push the branches that you want to keep to that repo. > > I've not yet administrated a sourceforge project so I don't know how this > works. But I've seen projects that had both an SVN and a Git repo. > > Regards, > > Thomas Koch, http://www.koch.ro > |
|
From: Peter P. <pit...@us...> - 2013-03-22 06:43:46
|
Hi Thomas, hi Ryan, Am 22.03.2013 um 06:52 schrieb Ryan Holliday <rya...@gm...>: > Hi Thomas, > >> Keeping the .jar files in the history would blow up the repository for >> everybody for the rest of the life of the jamwiki project without any benefit. >> Working with the repository only becomes slower. > > Losing the JAR files wouldn't be a huge problem, given the trade-off of > repository size. Old JAMWiki WAR files are available for download, SVN > will probably still be available, so losing JARs from old source code > history seems like an acceptable trade-off. I agree. If SVN is continued to be available there's no gain in transferring superfluous JAR files (that should never have made it to the SOURCE code management!) to git and only blow up it's size. I was only concerned about them getting lost completely and therefore establishing a situation that would make it impossible to re-build and older revision. That trade off is OK to me, as it's not the job of a new SCM to enable the most easiest way to re-build a historic version. >> I propose to review which branches we want to keep and to put the rest in some >> dark hidden corner of the internet. > > With regards to branches, as long as the release branches are kept > (branches/0.9.x, etc) and the release tags can be maintained then I > don't think anything else is needed. Peter - if you feel differently > please say so. I don't. SVN doesn't do branch tracking as Git, so there's no gain. All merges belong solely to destination trunk, so the commit log information where it originates from provides all information; Any further technical tracking of the original source is "manual work" anyway, so it can be done in SVN as well. I even don't mind about "my" personal branch; There's no problem in recreating it. All I see as "necessary" is - beneath "trunk" (or "master") - the release branches and tags. Everything else is an add-on :-) > Thanks for your work on this. Let me step into this chorus! Thanks for doing the job, I wouldn't have been able these days, due to workload. A little coding "by the way": yes; The focus requiring and time consuming SCM migration: sadly not right now :-) -- Best regards, Peter |
|
From: Thomas K. <th...@ko...> - 2013-03-22 06:35:42
|
Hi Ryan, the release branches and tags are available. I propose that you enable a Git repo on sourceforge and push the branches that you want to keep to that repo. I've not yet administrated a sourceforge project so I don't know how this works. But I've seen projects that had both an SVN and a Git repo. Regards, Thomas Koch, http://www.koch.ro |
|
From: Peter P. <pit...@us...> - 2013-03-22 06:34:10
|
Hi Ryan, Am 22.03.2013 um 06:55 schrieb Ryan Holliday <rya...@gm...>: > Hi Peter, > >> I'm ready to commit, it's just matter of merging my local separate branch into SVN. >> You should see the message on jamwiki-commit in a few minutes. > > I should be able to get your code merged and also add the needed upgrade > code for modifying the database column size this weekend. You had > mentioned possibly removing the extraneous 64 bit encoding step, so if > that will make the database schema change unnecessary let me know and > I'll hold off on putting the changes in trunk for now while we work out > the details. Please hold off the merge, I'm working on reverting the superfluous encryption step, exactly to make the DB upgrade unnecessary. I'll report back shortly. -- Regards, Peter |
|
From: Ryan H. <rya...@gm...> - 2013-03-22 05:55:37
|
Hi Peter, > I'm ready to commit, it's just matter of merging my local separate branch into SVN. > You should see the message on jamwiki-commit in a few minutes. I should be able to get your code merged and also add the needed upgrade code for modifying the database column size this weekend. You had mentioned possibly removing the extraneous 64 bit encoding step, so if that will make the database schema change unnecessary let me know and I'll hold off on putting the changes in trunk for now while we work out the details. Ryan |
|
From: Ryan H. <rya...@gm...> - 2013-03-22 05:53:19
|
Hi Thomas, > Keeping the .jar files in the history would blow up the repository for > everybody for the rest of the life of the jamwiki project without any benefit. > Working with the repository only becomes slower. Losing the JAR files wouldn't be a huge problem, given the trade-off of repository size. Old JAMWiki WAR files are available for download, SVN will probably still be available, so losing JARs from old source code history seems like an acceptable trade-off. > I propose to review which branches we want to keep and to put the rest in some > dark hidden corner of the internet. With regards to branches, as long as the release branches are kept (branches/0.9.x, etc) and the release tags can be maintained then I don't think anything else is needed. Peter - if you feel differently please say so. Thanks for your work on this. Again, let me know if there is anything specific that I can do to help out. Ryan |
|
From: Thomas K. <th...@ko...> - 2013-03-21 15:39:06
|
Hi Ryan, Peter, thank you for your feedback. I also want to keep all history of all important files. Since I work with Git I often look in the log to see the commit that introduced some line of code. See also this recent video on this topic: http://devblog.avdi.org/2012/06/22/use-revision-control-annotation-in-your- editor/ So I care a lot about the full history of all java and other code files. But I'd strongly propose to remove all .jar files from the history. They don't help to understand the code and would only be needed in the very unlikely case that somebody would want to build a jamwiki version from 2007. And even for this case we could keep the SVN and take the jars from there. Keeping the .jar files in the history would blow up the repository for everybody for the rest of the life of the jamwiki project without any benefit. Working with the repository only becomes slower. I've pushed a new version with all tags and branches to https://github.com/thkoch2001/jamwiki-wiki-conversion-wip2 I've only filtered the .jar files in this version. The history of the master branch is around 10MB. The additional history of the other branches is around 9MB. Most of the other files that I deleted in the last version are in the dfisla branch. I propose to review which branches we want to keep and to put the rest in some dark hidden corner of the internet. You can do selective clones to get only one branch with the --branch and -- single-branch options of git clone. Regards, Thomas Koch, http://www.koch.ro |
|
From: Ryan H. <rya...@gm...> - 2013-03-21 05:35:50
|
On 3/20/2013 1:45 PM, Peter Palmreuther wrote: > True, but in the end a SCM is supposed to enable revision safe state > tracking. We should, somehow, provide the full and uncut history; No > matter if someone right now want's to use it for production relevant > things ... But that's just my 2 cents ... I'd agree with Peter that ideally we would not lose history when changing source control systems, including the release branches. It's valuable to be able to trace the development of a file and review commit history to determine why things were done the way that they were done. I can delete most of the "personal" branches if that helps reduce the repository size, and I can provide file access if there is a fast way to download the entire SVN repository and convert it to Git. Alternately, if there are other options for simplifying this process let me know how I can help. In the end, if we have to lose some history it's not the worst thing in the world, but that's a trade-off that would be good to avoid if possible. Ryan |
|
From: Ryan H. <rya...@gm...> - 2013-03-20 21:51:02
|
Hi Peter, On 3/20/2013 2:16 PM, Peter Palmreuther wrote: > Does anybody know the rational behind applying a DES encryption to > SHA-512 hash of the password with a not so secret key? It looks to me like the extra encryption is just a remnant from the original VQWiki code that never got removed - it's there in revision 1 of Encryption.java. So long as the SHA algorithm is applied with a random salt then I think the password is sufficiently secure without the need for any additional processing. Provided it's backwards compatible with 1.2.x (or later) and doesn't open any security holes please feel free to make whatever cleanups you think are necessary. Ryan |
|
From: Peter P. <pit...@us...> - 2013-03-20 21:16:40
|
Hi Ryan, Am 19.03.2013 um 07:09 schrieb Ryan Holliday <rya...@gm...>: > On 3/16/2013 4:46 PM, Peter Palmreuther wrote: >> So it would be nice if someone could apply this patch to a local >> export of the sources and test if every thing works well; for me it >> does. Maybe someone can even test if an already existing installation >> still works ... After the necessary small upgrade. > > After updating the column size to 150 characters I ran your patch > locally without issue - it used my old password without issue > (unsalted), and after updating to a new password used the new password > with salt. When you're ready to merge this I can do a larger test with > some of the test sites I have. I've got another request: I saw the "encrypt64" method in Encryption, and for keeping things with introducing the salt I simply used existing infrastructure. After salting work I had some time and energy to inspect the other infrastructure elements. I couldn't see the reason behind DES encrypting password hash ... Does anybody know the rational behind applying a DES encryption to SHA-512 hash of the password with a not so secret key? In the end this makes the encrypted password 96 bytes, while directly Base64 encoding the hash would only require 56 bytes. This way the added salt (8) and hashing algorithm (7) and delimiters (3) would sum up to 74 bytes, which would fit into the current column size. It would make up updating a little more complex, as I'd need to write a DES decrypting routine, but that's not a big deal at all. It's just a matter of: is it OK? I don't know about enough real world installations and number of users that need to get migrated their data. The positive would be a less complex code with same security level, finally raised by enabling salting password once they're changed by their users. What's your opinion? -- Regards, Peter |
|
From: Peter P. <pit...@us...> - 2013-03-20 20:45:21
|
Hi Thomas, Am 20.03.2013 um 19:10 schrieb Thomas Koch <th...@ko...>: > I ran an svn-git conversion yesterday and need your feedback for two > decisions. [...] > > The .jar files alone make up more than 40MB. I propose to remove all .jar > files from the history. *hmmm* Is the SVN repository kept available online at SourceForge after migration has been finished? If yes, I wouldn't really mind, as history is kept intact. > I don't think that anybody plans to build the versions > from the pre-maven era. It's nice and important to have the history of the > java files from this time, but it's a burden to carry old .jar cruft around. True, but in the end a SCM is supposed to enable revision safe state tracking. We should, somehow, provide the full and uncut history; No matter if someone right now want's to use it for production relevant things ... But that's just my 2 cents ... > Additionally I found more files that I propose to delete. They might not even > be in the trunk branch: Maybe I'm pedantic, but I wouldn't do, without compensation. If we decide to "make a cut" and keep revisions "up to xxx" available for separate download, or checkout from still available SVN, I'm fine with this. But if you want to do a search "where does XYZ come from" you need a complete data basis. Unless I'm the only one, having this wish. In this case I'd not fight any deletion decision. > I've pushed a git clone with those files removed to: > https://github.com/thkoch2001/jamwiki-wiki-conversion-wip Thanks. > I've lost the branches during the conversion. But I could do the conversion > again with the branches, if you want. I'd prefer so, unless ... I know, I repeat myself ... we keep a separate history available (and therefore officially "(somehow) start from scratch"). There's http://danielpocock.com/migrating-a-sourceforge-project-from-subversion-to-git It additionally describes how to keep tags ... Which, IMHO, are even more important than branches (especially if they don't even differ significantly - in sense of unmerged code - from trunk). If development roadmap is "Next release will be 2.x" and "We make a kind of 'restart' including SCM house keeping", "For historical data see [SVN dump as compressed archive in SF files section or still read-only accessible SVN]" ... As from my perspective: let's go ahead! -- Best regards, Peter PS: Never mind the last commit to branch "pitpalme", if the decision is to cut history. I'll easily be able to re-apply it to a new repository! |
|
From: Thomas K. <th...@ko...> - 2013-03-20 18:11:03
|
Hi,
I ran an svn-git conversion yesterday and need your feedback for two
decisions. First I've attached the authors file used to map svn ids to git
names and emails. Please (Ryan) review this file and add or remove information
as you like.
Second: When trying to push the git repo to a server I killed the process
somewhere at 30MB. That is too large. I've then filtered out the largest files
in the history:
git log --all --format=format:%T | xargs -n 1 -d "\\n" git ls-tree -r --long
--full-name | cut -d " " -f4- | grep "^ *[[:digit:]]\{6,\}" | sort -u -n -r
The .jar files alone make up more than 40MB. I propose to remove all .jar
files from the history. I don't think that anybody plans to build the versions
from the pre-maven era. It's nice and important to have the history of the
java files from this time, but it's a burden to carry old .jar cruft around.
Additionally I found more files that I propose to delete. They might not even
be in the trunk branch:
Size Path
6607408 jamwiki-crawler/tests/over5ktopics.txt
4805907 doc/categories.txt
2564118 jamwiki-crawler/tests/over10ktopics.txt
1219322 webtests/lib/webtest/resources/build/WebTestReport.reference.xml
656932 rainers/lib-src/acegi-security-1.0.3-src.zip
495194 doc/AllExtensions.pdf
403283 jamwiki-analyzer/test-content/Anarchism.orig.pdf
379304 jamwiki-mysql/logs/single-topic-parse.log
334704 webtests/results/002_SearchSomeJamwik/WebTestReport.xml
313772 jamwiki-analyzer/test-content/Anarchism.orig.html
309257 jamwiki-war/src/main/webapp/FCKeditor/_whatsnew_history.html
306051 webtests/results/005_SearchSomeJamwik/WebTestReport.xml
264148 jamwiki-war/src/main/webapp/FCKeditor/editor/js/fckeditorcode_ie.js
261229 jamwiki-war/src/main/webapp/FCKeditor/editor/js/fckeditorcode_gecko.js
161434 jamwiki-mysql/logs/single-topic-load.log
132893 doc/templates.txt
127503 work/org/apache/jsp/WEB_002dINF/jsp/recent_002dchanges_jsp.java
100665 ehcache/Ehcache - Web Caching_files/Main.js
I've pushed a git clone with those files removed to:
https://github.com/thkoch2001/jamwiki-wiki-conversion-wip
The current tree has a size of 7.5 MB while the Git repo is 10 MB large.
Having the whole history locally thus adds an overhead of 2.5 MB.
I've lost the branches during the conversion. But I could do the conversion
again with the branches, if you want. However the only not yet merged from the
last year is "wrh2" with some cleanup commits. Is this branch still needed?
Regards,
Thomas Koch, http://www.koch.ro
|
|
From: Peter P. <pit...@us...> - 2013-03-20 05:39:52
|
Hi Ryan, Am 19.03.2013 um 07:09 schrieb Ryan Holliday <rya...@gm...>: > Hi Peter, > > On 3/16/2013 4:46 PM, Peter Palmreuther wrote: >> So it would be nice if someone could apply this patch to a local >> export of the sources and test if every thing works well; for me it >> does. Maybe someone can even test if an already existing installation >> still works ... After the necessary small upgrade. > > After updating the column size to 150 characters I ran your patch > locally without issue - it used my old password without issue > (unsalted), and after updating to a new password used the new password > with salt. When you're ready to merge this I can do a larger test with > some of the test sites I have. Thanks for the good news. I'm ready to commit, it's just matter of merging my local separate branch into SVN. You should see the message on jamwiki-commit in a few minutes. Thanks for testing, Peter PS: I assume you saw the password with salt in your database as well, after changing it? |
|
From: Ryan H. <rya...@gm...> - 2013-03-19 06:10:00
|
Hi Peter, On 3/16/2013 4:46 PM, Peter Palmreuther wrote: > So it would be nice if someone could apply this patch to a local > export of the sources and test if every thing works well; for me it > does. Maybe someone can even test if an already existing installation > still works ... After the necessary small upgrade. After updating the column size to 150 characters I ran your patch locally without issue - it used my old password without issue (unsalted), and after updating to a new password used the new password with salt. When you're ready to merge this I can do a larger test with some of the test sites I have. Ryan |
|
From: Ryan H. <rya...@gm...> - 2013-03-18 04:25:46
|
On 3/16/2013 4:46 PM, Peter Palmreuther wrote: > So it would be nice if someone could apply this patch to a local > export of the sources and test if every thing works well; for me it > does. Maybe someone can even test if an already existing installation > still works ... After the necessary small upgrade. I haven't tried running your code yet, but reading through the patch and approach it makes sense and looks fairly elegant. I can add the code to automatically detect an upgrade and increase the password field size in the database if you'd like - I'm looking into possibly using Flyway for schema management in 2.0, but until that happens a schema change is a simple matter of modifying UpgradeServlet and DatabaseUpgrades. With respect to the specific issue that I thought required Java 6, looking at http://jira.jamwiki.org/browse/JAMWIKI-36 I think that may have been related to the Jasypt library that is mentioned in the comments, but I don't recall specifically - I have vivid memories of working on this issue in the basement of the LA Cathedral while my girlfriend rehearsed for a Christmas concert, but I probably should have written down some notes as well :) I'll get your changes running locally in the next couple of days and let you know if I encounter any problems. If you'd like to commit it to a branch please go ahead. Thanks for working on this - it will be a nice security improvement that I know several people have wanted. Ryan |
|
From: Ryan H. <rya...@gm...> - 2013-03-18 03:50:42
|
On 3/16/2013 5:15 PM, Peter Palmreuther wrote: > Guava is pretty huge, so it's hard to tell ... But I'll take the > chance to get a better overview of JAMWiki code to see whether there > are, or not. In the end I don't think this is something that has to > be finished in once commit, so why not give it a start for 2.0 ;-) My only concern with using Guava is that it IS pretty huge, and it duplicates a lot of functionality from commons.io and ehcache, so I'd like to make sure that a) enough Guava functionality is being used to justify a 2MB increase in the JAMWiki war and b) we don't end up with two different ways of doing things like I/O or caching, as that gets confusing and makes code maintenance more difficult. That said, if you're comfortable with Guava then I'm happy to make switch, I'd just like to do so with the plan being that commons.io and ehcache are scheduled for removal, along with anything else that makes sense to remove if it duplicates Guava functionality. Ryan |
|
From: Ryan H. <rya...@gm...> - 2013-03-18 03:40:23
|
Hi Peter, Thomas, I just pushed out the JAMWiki 1.3.1 release. I don't think there is any hurry to get the conversion to Git done, but please send an email if any changes are imminent. If/when you need any specific permissions please let me know via private email what permission you need, and also remind me what your Sourceforge ID is, and I'll get that updated as quickly as possible. Let me know if there is anything specific that I can do to help out - I'll leave the actual Subversion-to-Git conversion to you guys, but I can assist with documentation and Maven updates. Ryan |
|
From: Peter P. <pit...@us...> - 2013-03-17 00:15:32
|
Am 16.03.2013 um 19:41 schrieb Thomas Koch <th...@ko...>: > Ryan Holliday: >> On 3/14/2013 8:39 AM, jam...@li... wrote: >>> Are you familiar with the Guava library? >>> http://code.google.com/p/guava-libraries >> >> I've actually been looking at replacing ehcache for caching, and don't >> have strong feelings about things like commons.io, so Guava is >> definitely worth considering. Have you used its caching functionality >> before? Any feedback? > I haven't used the caching stuff yet. Neither did I. But I had a quick look at http://guava-libraries.googlecode.com/files/JavaCachingwithGuava.pdf and it sounds promising. I'll try to get an idea, how and where and why current code base uses ehcache to figure, if and how Guava could be an appropriate replacement. >> I've never used Guava before, so are there other libraries or custom >> functionality in the JAMWiki codebase that it could replace besides >> commons.io and ehcache? Guava is pretty huge, so it's hard to tell ... But I'll take the chance to get a better overview of JAMWiki code to see whether there are, or not. In the end I don't think this is something that has to be finished in once commit, so why not give it a start for 2.0 ;-) -- Regards, Peter |
|
From: Peter P. <pit...@us...> - 2013-03-17 00:07:45
|
Am 16.03.2013 um 15:57 schrieb Thomas Koch <th...@ko...>: > Ryan Holliday: >> Given that my experience with Git is solely as a user and not as an >> admin, would either of you be willing to take the lead in the migration? > I volunteer. Nice. I'd have volunteered too, but my schedule wouldn't have permitted this that close. >> * Migrate the Subversion repository (hopefully with history) to Git. > No problem. >> * Update Maven to build and deploy to Git. > Will have to learn it, but will do so. Rather simple; Updating 'project.scm.connection', 'project.scm.developerConnection' and 'project.scm.url' should be sufficient. >> * Update build instructions. > Ok. That's a bit of work. Main issues should be done with updating 'Prerequisites' and 'Getting the Source' by exchanging SVN references to Git ... But than there's 'Source Repository Layout' and IDE related things ... If migration is done, I'd try to provide my help with updating the wiki pages ASAP. -- Regards, Peter |
|
From: Peter P. <pit...@us...> - 2013-03-16 23:46:20
|
Hi, Am 10.03.2013 um 20:14 schrieb jam...@li...: > I think the Encryption.bytes2String method can be killed - if I had to > guess that's probably just very old code and no one noticed the possible > cleanup. Did a SVN history search and the code came already with import from VQwiki. Cleaned it up, because I think it's useless and even more: dangerous. "new String()" is dangerous the very same way, but does not obfuscate this; So I preferred it for now, until I found a way to rearrange this stuff as a whole thing. > One caveat if you're looking into the password salts is to ensure that > any change will work for existing installations (or with an upgrade > process). I gave my very best. There's a small upgrade necessity, but I'll explain below. > I haven't looked at that issue in a long time, but as I > recall there was no easy way to upgrade existing installations to > support password salts using Java 5, I actually had and have no idea, why salts for passwords should be a matter of Java version, whether 1.4, 5, 6 or 7. I implemented salts without any known binding to used Java version. I created a comprehensive patch, which hopefully covers all relevant locations. I'll attach it to this mail. If this list blocks it, I'll upload it to some web space and share the link. The reason behind this is, I'd like to avoid committing an unchecked patch to my branch, that has to be reverted. "Unchecked" in the sense I'd like to have at least a second, even better third, opinion on the proposal for change. So it would be nice if someone could apply this patch to a local export of the sources and test if every thing works well; for me it does. Maybe someone can even test if an already existing installation still works ... After the necessary small upgrade. The details and my thoughts are in "README.md", contained in the mentioned attachment. So ... Feedback time :-) -- Best regards, Peter |
|
From: Thomas K. <th...@ko...> - 2013-03-16 18:41:49
|
Ryan Holliday: > On 3/14/2013 8:39 AM, jam...@li... wrote: > > Are you familiar with the Guava library? > > http://code.google.com/p/guava-libraries > > I've actually been looking at replacing ehcache for caching, and don't > have strong feelings about things like commons.io, so Guava is > definitely worth considering. Have you used its caching functionality > before? Any feedback? I haven't used the caching stuff yet. > I've never used Guava before, so are there other libraries or custom > functionality in the JAMWiki codebase that it could replace besides > commons.io and ehcache? I haven't seen enough of the jamwiki code to not miss many examples where guava could replace existing apache commons stuff. I've seen Stringutils.isBlank() which has an equivalence in guava. A list of nice praises of guava: http://stackoverflow.com/questions/3759440/the-guava-library-for-java-what- are-its-most-useful-and-or-hidden-features or do a video search for talks about google guava! Regards, Thomas Koch, http://www.koch.ro |
