xwiki-devs April 2012

xwiki-devs@xwiki.org

31 participants
86 discussions

Re: [xwiki-devs] [GSOC] A basic search implementation with SOLR

by savitha sundaramurthy

Hi Paul, Here is the link to the document https://docs.google.com/document/pub?id=1-2GqvjtzS_a8TRKDNsom9egDZHTT5xIzUf… Thanks a lot, Savitha > On Wed, Apr 4, 2012 at 12:03 PM, Paul Libbrecht <paul(a)hoplahup.net> wrote: > >> Hi Savitha, >> >> things are moving. This is good. >> >> Do you have a (temporary) server address where this could be tested? >> (maybe best over IRC?). >> Or, how could I build your code and inject it on a fresh XWiki? >> >> Le 4 avr. 2012 à 18:46, savitha sundaramurthy a écrit : >> > I went through Fabio Mancinelli's code and with the help of few >> > inputs from there , I have implemented a basic search functionality >> using >> > solr. It also fixes the issue http://jira.xwiki.org/browse/XWIKI-6226. I >> > have indexed the page in English, french and Spanish. I have implemented >> > these main functionality: >> > >> > 1) Simple text search using solr. >> > 2) Used *Extended Dismax Parser *to customize search relevancy using >> boost >> > index. >> >> which fixes well the apostrophe case for sure (and a zillion other >> ambiguities, and another zillion power user tricks). >> >> > 3) Hit highlighting for English. >> >> This is a good usage of solr. >> >> > Below is the link to the source code >> > https://github.com/savis/xwiki-platform-search >> > XWiki front end , HTML and Velocity code >> > >> > https://gist.github.com/2295648 >> > >> > I wanted to send a pull request but I was playing around when renaming >> my >> > username and deleted the forked repository and I'm having difficulty >> > forking it again. So I have created a new repository and shared the code >> > above. >> >> I think forking is really useful. If not today, it will be needed any day >> soon. >> We need to see the diffs. >> Best would be to create the fork again, then copy your files and let git >> give us the diff. >> >> > I have taken few screen shots and have attached the document. >> >> where? >> >> > I'm working on my application and it should be done today. >> >> What is the planned schedule? >> >> paul >> _______________________________________________ >> devs mailing list >> devs(a)xwiki.org >> http://lists.xwiki.org/mailman/listinfo/devs >> > > > > -- > best regards, > Savitha.s > -- best regards, Savitha.s

12 years, 8 months

[xwiki-devs] XWiki on cloud environments

by Fabio Mancinelli

Hi everybody, at XWiki we are participating in different research activities, many of them focused on cloud computing. As a part of this research efforts we've build this project that allows you to deploy XWiki in different cloud environments. In the current state, it allows to build an XWiki distribution that can be deployed on Amazon Beanstalk (http://aws.amazon.com/elasticbeanstalk/) and can also take advantage of the Amazon S3 Blobstore (http://aws.amazon.com/s3/) for storing attachments. The project is extensible, so other environments could be supported (e.g., Openstack SWIFT blobstore, http://swift.openstack.org/) and also deployment that are dynamically configured when started in virtual machines that are started up in other platforms. If you want to have a look you can find it here: https://github.com/fmancinelli/xwiki-platform-cloud For the moment I've put it on my personal GitHub account but I'll move it to XWiki contrib as soon as possible. Thanks, Fabio P.S.: If you want to experiment with it, Amazon provides a free usage tier (http://aws.amazon.com/free/)

12 years, 8 months

[xwiki-devs] Blog.CreatePost forwarded to wrong url

by du du

Hi, all, I got a weired problem with url handling, when I am on this page: http://mydomain.com/xwikim/bin/view/Blog/CreatePost, which gives me a create post button to create post, I check the form action url is: "/xwikim/bin/view/Blog/CreatePost?xpage=plain", when I click on the create button, it comes to this url: http://localhost/xwikim/bin/edit/Blog/Post+title?template=Blog.BlogPostTemp…, from which I got "Unable to connect" error, I am not sure why it switched from mydomain.com to localhost, all other links and buttons are working fine without this kind of problem. My setup is like that I have an apache web server installed with port 80 opened to the public internet, which forwards request to tomcat with port 8082 on localhost. all other links work fine, only the createpost has this problem. Any clue from any of you? Thanks very much in advance Dave

12 years, 8 months

[xwiki-devs] XWikiPreferences Source Code

by du du

Hi, all, One question, I am trying to look at the source code of XWikiPreferences class, AdminSheet class, but after I searched Data Type, I got a lot of classes back, I clicked on these two classes, it always shows the rendering result, I have no way to look at the velocity code behind the classes, but other classes like BlogClass, I can go inside the BlogSheet and use Edit button - Wiki to see the velocty code, why for these two classes I cannot see the code, any ideas? Thanks Dave

12 years, 8 months

[xwiki-devs] File Upload Page

by du du

Hi, all, I am trying to add a file upload page to xwiki, since the FileUploadPlugin java class is deprecated, is there any other fileupload component available for reuse? if no, I need to create the component on my own, my concern is I need to insert the file uploaded into database and keep it separate from all the other wiki tables, I like to create a separate table specifically for files uploaded, that means I need to use Hibernate in java code to handle that, any examples about how to do that? BTW, I am coming from IBatis background. Thanks in advance Dave

12 years, 8 months

[xwiki-devs] [VOTE] Use ComponentManager.getInstance*() instead of lookupComponent/LookupList/LookupMap

by Vincent Massol

Hi devs, In another thread we had a discussion about the new name of the method for looking up components. We had to provide a new one since we introduced support for Types in http://jira.xwiki.org/jira/browse/XCOMMONS-121 Thomas has introduced a new lookupComponent() method and has asked in a mail to speak up if we wanted a different name. I have replied to this thread and explained why I preferred a new one (see http://markmail.org/message/lvah3d6f37ak66p3). I'm copying my rationale here: " All looks good except CM.lookupComponent() which Ï don't like a lot for the following reasons: * It's a bit long. It's longer than before and it would be nicer if it were as short as before or even shorter ;) * It's not symmetrical with other lookups like lookupList and lookupMap, which should theoretically be lookupComponentList() and lookupComponentMap() which are even longer " I've proposed several possibilities and some committers have expressed their preferences for getInstance*() so I'm officially proposing it here as a VOTE since it's an important API that we're going to keep for a long time ;) So this vote is about using: * CM.getInstance(…) * CM.getInstanceList(…) * CM.getInstanceMap(…) Rationale: * Shorter than lookupComponent, LookupComponentList, LookupComponentMap * This is what is used in Guice and Picocontainer and seems to be a well-known name Here's my +1 IMPORTANT: Please vote quickly since we need to agree before the release of 4.0 final and 4.0RC1 is planned for this coming Monday so it would be ideal to speed up this vote and do the change today if we agree about it. Thanks -Vincent

12 years, 8 months

[xwiki-devs] [VOTE] Postpone 4.0RC1 release to Tuesday 10th

by Thomas Mortagne

Hi devs, I won't be available to release 4.0RC1 next Monday which is the planned release date so unless someone else want to do it we need to move it. I see two possibilities: 1) today 2) next Tuesday Here is my +1 for 2) for the following reasons: * we slipped a bit with 4.0M2 which mean that it has just been released this week which makes it too short to release the RC1 today IMO * we need to finish with new ComponentManager API (please answer to Vincent's vote mail) before the release candidate or then it's not a release candidate * I would like to finish with relative vs absolute URL in sendRedirect so that this change is introduced in a new major version (but it's more nice than critical) * anything else left to do for 4.0 ? -- Thomas Mortagne

12 years, 8 months

[xwiki-devs] [Proposal] Choosing the default component implementation

by Sergiu Dumitriu

Hi devs, Currently, requesting a component instance without a hint will look for the implementation that uses the "default" hint, which makes it difficult to change the implementation in an XWiki instance. Sure, it is easy as long as all the implementations use the "default" hint, but choosing the default between alternative implementations that should all still be usable by themselves is not possible. Also, "default" is not really a good hint, since it describes the state of the implementation, not the technology, the aspect that makes it different from the others. It would be better to name each implementation with a proper hint. I propose to define a mapping that can specify which hint is the default for a component. In a text file, META-INF/component-defaults.txt, we'll keep componentinterface=defaulthint mappings. For example: com.xpn.xwiki.store.XWikiStoreInterface=hibernate com.xpn.xwiki.store.migration.DataMigrationManager=hibernate And then, when we lookup the current storage implementation, we don't need to check what is the configured hint in xwiki.cfg (or xwiki.properties), we can just request the default implementation. If there's no mapping for a component, we'll continue to use the "default" hint. I'm not sure where exactly to keep such files. We bundle a components.txt file in each jar containing component implementations. We could do the same for the components we consider the platform defaults, and allow overrides in the WEB-INF/classes/META-INF/component-defaults.txt file. Still, this means that whenever platform defaults change, we need to keep another special section in the release notes, to let users know about these changes, so that they can manually revert to the old default if they need to. In the future we could change existing components to give proper hints instead of "default", where such a change is applicable. Another idea is to not use "default" at all, and instead go for a generic "xwiki", "xe", "xwiki-platform" or something like that whenever there's just one implementation for a component and we can't find another hint to describe it. WDYT? -- Sergiu Dumitriu http://purl.org/net/sergiu/

12 years, 8 months

[xwiki-devs] monitoring the cache: how to get the eviction rate?

by Paul Libbrecht

Hello developers, I have been doing a nifty little cache monitor on www.curriki.org which is still running xwiki 1.5.4. It can show the entries and capacity of the two xwiki caches, pageExistCache and the document cache which sound pretty central. Not surprisingly, they're both full on our production server. name entries capacity pageExistCache 10000 10000 cache 3000 3000 The caches are using OSCache (through "OSCacheCache"). I've been trying to get a real statistical count but there I kind of failed thus far. I can use the StatisticListenerImpl which gives fairly high numbers: > StatisticListenerImpl: Hit = 9583563 / 1320251374, stale hit = 0 / 538, miss = 8541 / 17175236, flush = 27348, entries (added, removed, updates) = 25457741, 0, 7678101 these numbers are integers, and might actually be too small for the 2billions limit of an int, they are static (so count "all the OSCache instances"). What I would like to get is the "eviction rate" but I do not know how to compute it. That is, I wish to read the number of cache-entries which are thrown away because the cache is full and others come in. Once I can have it, I can start tuning (cache size, less greedy algorithms, ...) and measure the effect of such tuning. We have plenty of RAM space to accommodate the cache but we should use this well. The big annoyance with this process is that it can only run on our production server. So thus far I did not dare register a CacheListener in groovy fearing it would suddenly be slow. Has anyone used a different strategy or tool? I'm happy to post my little monitor script. thanks in advance. paul

12 years, 8 months

[xwiki-devs] Extension "Resolve Maven Pom" clarification on an issue

by jerem

Hello, I'm using the Extension module and the resolve maven pom to parse some poms installed in a local repository. As I have some failures, I realized I was hitting this bug : http://jira.xwiki.org/browse/XWIKI-7641 My question is on understanding this text from the issue : Where is stored the AETHER cache repository on a wiki instance ? Thanks, Jeremie -- View this message in context: http://xwiki.475771.n2.nabble.com/Extension-Resolve-Maven-Pom-clarification… Sent from the XWiki- Dev mailing list archive at Nabble.com.

12 years, 8 months

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs April 2012