Sigh... leaving...
Guys (and gals if we have any), As much as I've wanted to help more with Solr development, I haven't had time, and I don't see any time opening up in the near future. So I'm going to unsubscribe from the dev and PPMC lists. You all obviously know how to reach me if you need me for some particular reason, and I'll be happy to help in that case ;) Thanks, and please keep up the good work, Solr is awesome. Yoav
Re: Is Solr ready for graduation?
Hi, For the curious, here's what votes will be needed and what's binding in them. It may seem like a long road, but don't be discouraged: for a project like Solr, there's largely consensus so these votes are quick and painless. First, the Solr PPMC must approve the graduation request. In this vote, Solr PPMC members' votes are binding. Unless I'm mistaken, right now all Solr committers are also PPMC members, or close to it. Next, the adopting PMC (in this case Lucene) must vote to accept Solr. In that vote, only Lucene PMC members' votes are binding; you can see those people at http://lucene.apache.org/who.html#Lucene+PMC . Finally, after the Lucene PMC approves, we ask the Incubator PMC. In that vote, Incubator only PMC members' votes are binding. You can see that list of people at http://incubator.apache.org/whoweare.html . You will note at least several people (such as Yonik and Erik Hatcher) will have binding votes in more than one of the above votes. That's fine, it's even expected, e.g. from mentors. They can wear multiple hats without (hopefully) acquiring some clinical disease. Yoav On 1/4/07, Bill Au [EMAIL PROTECTED] wrote: +1 on going for graduation. Bill On 1/4/07, Erik Hatcher [EMAIL PROTECTED] wrote: And, of course, likewise. Solr is more than ready to get voted on for graduation. Erik On Jan 4, 2007, at 4:21 AM, Bertrand Delacretaz wrote: On 1/3/07, Yoav Shapira [EMAIL PROTECTED] wrote: ...I'd say definitely ask Lucene first. (And in general ask the accepting TLP first, before asking the Incubator). +1 from me to starting the discussion, and +1 for graduating Same opinion on all points here. -Bertrand
Re: Is Solr ready for graduation?
Hi, I'd say definitely ask Lucene first. (And in general ask the accepting TLP first, before asking the Incubator). +1 from me to starting the discussion, and +1 for graduating. Yoav On 1/3/07, Yonik Seeley [EMAIL PROTECTED] wrote: What do people think? As you may know, graduation is not so much about code maturity/quality as it is about community (in addition to making sure all the legal IP issues are covered). The primary hurdle that Solr faced starting from a closed-source project was building a diverse community (including independent committers). Another recent Incubator recommendation was to make a release, to show we knew the process and to uncover any potential IP or licensing issues. With the release of Solr 1.1, we've now covered that base as well. The next steps would be to get approval from both the Incubator PMC and the Lucene PMC (the order is fuzzy, but this http://incubator.apache.org/incubation/Incubation_Policy.html#Exiting+the+Incubator the Incubator PMC SHALL provide a recommendation to the TLP that the Podling is ready to escalate. suggests that it's the Incubator that should go first). *But*, the incubation checklist suggests otherwize: If graduating to an existing PMC, has the PMC voted to accept it? http://incubator.apache.org/projects/solr.html The latter makes more sense to me, so I'd vote to ask the Lucene PMC first if we decide we are ready. -Yonik
Re: ^M in example files
The ^M is a DOS (and now Windows) carriage return character. The fact you're seeing it indicates an improper encoding, properly caused at the last SVN commit for that file. The SVN way to deal with this is to set the svn:eol-style native property, best done once and for good in the SVN client configuration. See for example http://wiki.apache.org/cocoon/SVNConfig or google for svn:eol-style native. Yoav On 12/27/06, Anthony Kitchin [EMAIL PROTECTED] wrote: Hi, I have previously been using the nightly builds but since the release has come out I've thought to use that instead. I've been trying to setup replication on the 1.1.0 release and was delayed because the example/solr/conf/scripts.conf has ^M in it. And not being totally familiar assumed that the ^M were normal. But after a little more investigation the nightly builds that I'd previously used do not have these characters. And when you try to login as 'solr-user^M' it gives some rather crypic error messages and takes a while to debug. Hope this helps :-)
Re: Solr 1.1 released
Yup, definitely good stuff. Nice, speedy release process too, especially compared to other Incubator release approvals. Yoav On 12/23/06, Erik Hatcher [EMAIL PROTECTED] wrote: *clink* wonderful job, Solr team! Erik On Dec 22, 2006, at 5:14 PM, Bertrand Delacretaz wrote: On 12/22/06, Yonik Seeley [EMAIL PROTECTED] wrote: ...Solr 1.1 is now available for download!... Yoo-hooh, congratulations, virtual champagne everybody! -Bertrand
Re: release requirements status
Wow, cool. Yoav On 12/1/06, Yonik Seeley [EMAIL PROTECTED] wrote: Ahh, here's the pointer: http://www.apache.org/dev/release.html ''' If A Distribution Contains Code Under Several Licenses, Should It Contain Several License Files? No - all license information should be contained in the LICENSE file. When a distribution contains code under several licenses, the LICENSE file should contain details of all these licenses. For each component which is not Apache licensed, details of the component and the license under which the component is distributed should be appended to the LICENSE file. ''' -Yonik On 12/1/06, Yonik Seeley [EMAIL PROTECTED] wrote: On 12/1/06, Yoav Shapira [EMAIL PROTECTED] wrote: I thought this was exactly what the NOTICE file is for? Mention all the code from other projects we use, including ASL code. LICENSE is just for our own (Solr) stuff. LICENSE needs to apply to everything in the distribution. Solr's current LICENSE has ASL 2.0, followed by the license for the XML parser we use, as directed by legal-discuss. -Yonik
Re: release requirements status
Ooops, sent a bit too early -- meant wow, I was really wrong about this, good to know and cool, thanks for pointing it out ;) Yoav On 12/1/06, Yoav Shapira [EMAIL PROTECTED] wrote: Wow, cool. Yoav On 12/1/06, Yonik Seeley [EMAIL PROTECTED] wrote: Ahh, here's the pointer: http://www.apache.org/dev/release.html ''' If A Distribution Contains Code Under Several Licenses, Should It Contain Several License Files? No - all license information should be contained in the LICENSE file. When a distribution contains code under several licenses, the LICENSE file should contain details of all these licenses. For each component which is not Apache licensed, details of the component and the license under which the component is distributed should be appended to the LICENSE file. ''' -Yonik On 12/1/06, Yonik Seeley [EMAIL PROTECTED] wrote: On 12/1/06, Yoav Shapira [EMAIL PROTECTED] wrote: I thought this was exactly what the NOTICE file is for? Mention all the code from other projects we use, including ASL code. LICENSE is just for our own (Solr) stuff. LICENSE needs to apply to everything in the distribution. Solr's current LICENSE has ASL 2.0, followed by the license for the XML parser we use, as directed by legal-discuss. -Yonik
Re: [RT] working with patches vs. branches?
Hi, I mostly agree with Hoss and Yonik. Use patches, it's easy, trunk doesn't have to be stable, retain the Review Then Commit (RTC) style of development. Keep development fluid, don't gate it with more process than necessary (e.g. major branch merging). Branches are significantly easier with SVN than they were with CVS, for sure. Even so, I only think they're worth the maintenance and merging hassle for really major things. Of course really major is subjectives, so here are some examples. In Tomcat we traditionally made a branch only for major versions of the server (3.x, 4.x, 5.x, 6.x) that implement new versions of the Servlet and JSP specifications. Work is done only on the trunk for many months at a time. In log4j we've never really had concurrent development on multiple branches, work is done in the trunk, just like Lucene. The other incubating projects I'm currently involved with (OFBiz, lokahi, XAP) are the same way as Hoss and Yonik described for Solr. That said, if a developer has a major piece of work he/she wants to work on, and feels uneasy about doing it on trunk, he/she is more than welcome to create and maintain a branch for this purpose. The onus is on him/her to properly merge the work back once there's consensus the branch work should be included in the trunk. So we don't need to be zealous about branches / no branches (and I don't think anyone here is). Yoav On 11/17/06, Yonik Seeley [EMAIL PROTECTED] wrote: On 11/17/06, Chris Hostetter [EMAIL PROTECTED] wrote: : IIUC the agreed way of working is to do all important changes as : patches in Jira, discuss them and only commit once we agree on them? I would rephrase as: attach to jira, see if any one has comments/objections and commit once they've had a little time to soak. For changes that a committer feels are obvious or non-contentious (and not likely to be improved by review), I think they should just commit them. We have a review-after-commit policy too. For example, Mike's recent fix of field boosts was an important fix, but simply committing it w/o a JIRA issue was fine IMO. Changes of any nature that are copyrightable (have originality, etc) and come from non-committers should go through JIRA I think (for IP documentation purposes). People should be able to count on the fact that commits without JIRA issues originate from committers only. As far as branches go, I've not used them (because Lucene really hasn't), so I don't have much to go by. I would be concerned about the ability to easily see what a patch consists of from a simple link in the JIRA bug though. -Yonik http://incubator.apache.org/solr Solr, the open-source Lucene search server
Re: incubator report due
Looks good to me. +1 Yoav On 11/7/06, Yonik Seeley [EMAIL PROTECTED] wrote: Report to the Incubator is due by this Friday. I've put together a preliminary report already. http://wiki.apache.org/incubator/November2006 -Yonik
Re: changes before release?
Hi, On 10/9/06, Yonik Seeley [EMAIL PROTECTED] wrote: There is other stuff that needs to be done before we can release, such as a change of copyright notices to comply with new ASF requirements. I imagine incubator-general will go over the first release we make with a fine-tooth comb looking for compliance with ASF release rules. Yes. Speaking with my incubator PMC hat on, I think we should do the release prep stuff (LICENSE and NOTICE files, license resolution, etc.) first before the technical things, because we know less about them, they're required, and we are likely to underestimate the effort. On 10/9/06, Mike Klaas [EMAIL PROTECTED] wrote: The most important things that come to mind: - stabilize/review external api (query parameters, schema.xml/solrconfig.xml format, XML response format). (for instance, should debugQuery/explainOther combo be changed to debug/debug.otherQuery? Is the other query explain functionality important?) Yes, important, but not essential. Whatever release we do first is likely to be an alpha release to show a healthy and active community and focus on non-technical issues towards graduating from the incubator. - review/trim internal api. Not as crucial as the above, but still important. An example is that fields have two write() methods, one for the old XMLWriter and another for a generic TextResponseWriter. Perhaps we could make a parent interface for output writing so that this can be reduced to one method (the methods are identical for most of defined fields). Plenty of those examples around, all worthy of review and trimming, but see above. - remove all deprecated/compatibility code. Yes, and this one actually has a bonus in that we don't have to worry about licensing / noting (in our release documentation) any source we don't ship... Yoav
Re: Solr on Lucene home page?
+1. Yoav On 9/12/06, Bill Au [EMAIL PROTECTED] wrote: +1 Bill On 9/12/06, Chris Hostetter [EMAIL PROTECTED] wrote: : Should Solr have a tab on Lucene's home page? Other incubating : Lucene-related projects do. I think it would be appropriate. Oh yeah ... I forgot Lucene4c is in incubation too. +1, i'm all in favorof more solr visibility. -Hoss
Re: Re: Solr and UIMA?
Hi, I thought we discussed this already, mostly concluding UIMA was an IBM-proprietary bear that's not only far from a standard at this point, but not that promising and therefore not worth pursuing. But it could be that we didn't actually have that discussion on this mailing list: I may have had it in private with a couple of friends who use Solr instead. Does anyone else remember discussing it here, perhaps among the committers before we had the public solr-dev mailing list? Yoav On 8/23/06, Bertrand Delacretaz [EMAIL PROTECTED] wrote: On 8/23/06, Erik Hatcher [EMAIL PROTECTED] wrote: What exactly is the UIMA standard? I didn't see a standard mentioned at the UIMA site... I don't know if standard is the correct word, but [1] mentions an IBM product that exposes the UIMA interfaces, so there must be an API of some kind. But it's not too easy to gather from that website, exactly what this API is ;-( From [2] it seems like one of the main goals is to allow analysis engines to be plugged in on the way to indexation, to add metadata to what they call Common Analysis Structure objects. That page also links to a (364 pages long...) SDK Users Guide and Reference, [3]. -Bertrand [1] http://www.research.ibm.com/UIMA/ [2] http://www.research.ibm.com/UIMA/UIMA%20Architecture%20Highlights.html [3] http://dl.alphaworks.ibm.com/technologies/uima/UIMA_SDK_Users_Guide_Reference.pdf
Re: setting appropriate content-type
Hi, On 7/12/06, Yonik Seeley [EMAIL PROTECTED] wrote: So, right now, the Solr servlet always sets a content type of text/xml;charset=UTF-8 before getting the Writer to write the response. snip / So the new method is QueryResponseWriter.getContentType():String, and I also pass the request and response so content-type could change based on either of those. Make sense? Any other suggestions? Makes sense, no problem there. Just a minor / side comment: you should check that the response is not committed before setting the content type. That provides better support for filtering, e.g. some earlier or later Filter in the processing chain to set the response type. A lot of sites nowadays, for example, have a Filter that sets content type on UTF-8 for everything. It's a nice way to do content type in a universal manner without modifying every single servlet. As I said, just a side comment, tangential to your approach here, which I think is fine. Yoav
Re: bundled example appserver (Jetty vs Tomcat)
Hi, I'm biased towards Tomcat in this case for a couple of reasons, as previously noted: - It's an Apache product, and so is Solr. Mortbay is nice about Jetty, but it's a commercial enterprise and I would rather not depend on it for anything as important as the default distro. (Naturally, I'm in favor of making it easy for users to plug in their servlet container of choice in their own setup). - Relying on the current working directory (CWD) in any enterprise application is an evil on the same order as peppering your code with System.exit() calls. Let's not do it in Solr, it's a very slippery slope. (Note this isn't specifically anti-Jetty, just let's not do this in general, and you noted Jetty allows this while Tomcat does not). - You can change the logging.properties that Tomcat uses to your heart's content, including enabling only a console logger or whatever. It's pretty easy to do. Costin (one of the Tomcat developers) has been working on essentially a one jar version of Tomcat for 6.0, the next major Tomcat release. I don't speak for him, and I don't know its current status, but his intent and plan was to make it possible to run Tomcat as java -jar tomcat.jar and that's it. It's not in Tomcat 5.5, heck it may never be ready, but it's worth mentioning since you brought up the one-jar point (which I agree is a very nice thing in Jetty). And as you said, no flamewars. I think Jetty and its developers are cool, competent, I use it myself sometimes, have nothing against it. But I think Tomcat is better for Solr as the example bundle for the above reasons. Yoav Yoav On 6/20/06, Yonik Seeley [EMAIL PROTECTED] wrote: The servlet container we bundle for the example server, Jetty, is turning out to have a number of bugs (or maybe just a few that multiple people have all hit) in the new 6.0 line, and the 5.1 stable line. Nice things about Jetty vs Tomcat: - very easy to start java -jar start.jar, and more foolproof than Tomcat since we rely on $cwd for the demo to find the solr home ./solr - fewer files, esp in bin... easier to understand what is needed and what is not - log messages appear right on console, so errors are immediately apparent. You don't have to teach users how to go look through multiple log files, and you don't have to teach them about shutting down the server (just the normal CTRL-C) Nice things about Tomcat 5.5 vs Jetty 5.1: - more stable! - doesn't require a JDK... can run with a JRE (Jetty6 could as well since it uses JDT) - biggest user community, better docs, better support - slightly faster (in my micro benchmark sending deletes to Solr) So, I'm obviously leaning toward Tomcat, esp if we can make it easy enough for new users. Maybe make our own start script that calls Tomcats (blech) and maybe tails a log file for better error feedback??? Maybe it's just a matter of education/documentation, esp in the tutorial? No flame wars please ;-) (for people who don't follow the lucene dev list, this is a reference to the current java5 discussion over there) Thoughts? -Yonik -- Yoav Shapira Nimalex LLC 1 Mifflin Place, Suite 310 Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com
Re: Ant, Javadoc, and JUnit
Hola, Like a couple of other people, I wasn't a big fan of Maven 1, so always voted against it as the canonical build system, especially since Ant is still much more widely supported. However, I think Maven 2 brings great improvements, so I don't mind us at least trying it out to see how it works. FWIW, Maven 1 had a way (a plugin in maven terminology) to generate a pure Ant build.xml file from a Maven POM. I'm sure Maven 2 still has this capability, which would obviously reduce our maintenance burden. Yoav On 5/30/06, Darren Vengroff [EMAIL PROTECTED] wrote: I think your side-by-side proposal is a good one. Let me polish the pom a little and then I'll submit it. This will happen the first time I get a free moment in the next few days. -D -Original Message- From: Chris Hostetter [mailto:[EMAIL PROTECTED] Sent: Monday, May 29, 2006 1:35 PM To: solr-dev@lucene.apache.org Subject: RE: Ant, Javadoc, and JUnit : I hope it's not too off topic, but since you are hacking away at the build, : I'll ask. Have you thought of moving from Ant to Maven2? I'm new to solr, : so if it's been hashed over and rejected for valid reasons, excuse my : intrusion. have i personally thought about it? no. has anyone else thought about it? i don't know. has it ever come up in discussion on the mailing lists? no. I don't know about any one else, but I don't have any particular affinity for ant other then: it's what i know, it works fairly well, and it's fairly common so using it in the project doesn't create any immediate hurdle for new developers wanting to build solr. If maven(2) is better then ant in these respects, then i'd be happy to switch, but it doesn't quite seem like there's any serious motivation to do so -- particularly on that last point, maven isn't quite as common as ant is it? (let alone maven2). I get the early adopter chicken and egg problem for tools, but at ths point Solr is still in the trying to get noticed phase and supporting the least common denomiator is probably a good idea. : FWIW, I just put together a quick Maven2 pom.xml file for Solr and it seems : to work well. It's probably not be practical for general use until Lucene : itself uses Maven2, but I'd be happy to contribute it if and when that : happens. Definitely! ... if you'd like to contribute it now, it could probably live side by side with the build.xml so people comfortable with maven could use it instead if if they prefer ... right? (or is my vast lack of understanding about maven showing through here?) -Hoss -- Yoav Shapira Nimalex LLC 1 Mifflin Place, Suite 310 Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com
GData GSoC application
Guys, There's an application active for the Solr GData server idea as part of the Google Summer of Code, but no one has volunteered to mentor it. Other than me, is anyone here signed up as a GSoC mentor, and if so are you willing to mentor this project? -- Yoav Shapira Nimalex LLC 1 Mifflin Place, Suite 310 Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com
Re: patch submission
Hola, My question: what's the preferred way to submit patches? Should I just send them to this list? Post them to our issue tracker, JIRA, at http://issues.apache.org/jira/browse/SOLR. Consult http://www.apache.org/dev/contributors.html for actual tips like preferred patch format if unsure. And thanks in advance for contributing ;) Have a great weekend, Yoav
Re: GData
Hola, It might actually be a simpler project if it were standalone: not built into Solr, but rather a Lucene contrib project. One only has to write a few servlets that translate each requests into Lucene events: add, delete, delete+add, or query. It wouldn't have lots of Solr's fancy features (faceted searching, replication, etc.) but could still be a very useful thing. Do folks think that would be a tractable SoC project? Doug Yeah, and a cool one at that, +1. Yoav
Re: GData
Good. I'll be available on a time-permitting basis as always, but I don't want to commit as a mentor for this, so having you two makes me feel at ease ;) Yoav On 4/20/06, Yonik Seeley [EMAIL PROTECTED] wrote: On 4/20/06, Doug Cutting [EMAIL PROTECTED] wrote: Would you (or someone else) be willing to co-mentor this one with me? I'm travelling the month of July, so I'm hesitant to be the sole mentor. (I'll be online, but at reduced capacity.) If I have a co-mentor, then I'd be happy to write up the proposal. OK, I'm up for it... I don't really know my summer schedule, but I doubt I would be out more than a week at a time. -Yonik -- Yoav Shapira Nimalex LLC 1 Mifflin Place, Suite 310 Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com
Re: multiple solr webapps
Hola, No, don't use getServletContextName(). Besides being optional, it doesn't necessarily related to a path on the disk. For that matter, don't use the disk path approach anyhow, as things get quirky / fragile for users running packed WARs. There are a couple of alternatives, one using the classpath and one using the ServletContext#getResource approach. The classpath one is the standard Java classpath resource lookup mechanism: in your class, do getClass().getResource(path.to.your.resource) -- in a webpp, this will automatically use the webapp's specific classloader by default, so if you have a config file in WEB-INF/lib or WEB-INF/classes, it will get picked up. (And conveniently, one could specify server-wide Solr defaults in a higher classloader like the common server one). The ServletContext one is very similar: use ServletContext.getResource with the same path semantics, and a resource anywhere under your webapp root will be fetched. To compare / contrast the two: the ServletContext approach depends on a servlet container, i.e. is hard to use and test from a command-line utility. It also doesn't provide the hierarchical defaulting mechanism as easily as the classpath one. On the flip side, some people only like to have classes on the classpath in the name of neatness although in reality, there are a lot of things (for example DTD, XSD spec files) on the classpath at runtime. If you need a more concrete example of how to do this, I'll be glad to provide one. Yoav On 4/18/06, Yonik Seeley [EMAIL PROTECTED] wrote: On 4/18/06, Chris Hostetter [EMAIL PROTECTED] wrote: (or does ServletContext.getServletContextName() not do what I think i remember it doing) Unfortunately not the javadoc says it comes from the web.xml java.lang.String getServletContextName() Returns the name of this web application corresponding to this ServletContext as specified in the deployment descriptor for this web application by the display-name element. -Yonik -- Yoav Shapira Nimalex LLC 1 Mifflin Place, Suite 310 Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com
Re: multiple solr webapps
Yeah, it should. IMHO that call was only added as a kowtow to people demanding an easy hack approach -- and there's something to be said for that, if many people demand it. But it was still added half-heartedly, as it requires a request, i.e. you can't use it an initialization time before any requests come have arrived... Yoav On 4/18/06, Bill Au [EMAIL PROTECTED] wrote: But shouldn't the return value of HttpServletRequest.getContextPath() be the same independing of packaging (WAR or no WAR)? Bill On 4/18/06, Yoav Shapira [EMAIL PROTECTED] wrote: Hola, No, don't use getServletContextName(). Besides being optional, it doesn't necessarily related to a path on the disk. For that matter, don't use the disk path approach anyhow, as things get quirky / fragile for users running packed WARs. There are a couple of alternatives, one using the classpath and one using the ServletContext#getResource approach. The classpath one is the standard Java classpath resource lookup mechanism: in your class, do getClass().getResource(path.to.your.resource) -- in a webpp, this will automatically use the webapp's specific classloader by default, so if you have a config file in WEB-INF/lib or WEB-INF/classes, it will get picked up. (And conveniently, one could specify server-wide Solr defaults in a higher classloader like the common server one). The ServletContext one is very similar: use ServletContext.getResource with the same path semantics, and a resource anywhere under your webapp root will be fetched. To compare / contrast the two: the ServletContext approach depends on a servlet container, i.e. is hard to use and test from a command-line utility. It also doesn't provide the hierarchical defaulting mechanism as easily as the classpath one. On the flip side, some people only like to have classes on the classpath in the name of neatness although in reality, there are a lot of things (for example DTD, XSD spec files) on the classpath at runtime. If you need a more concrete example of how to do this, I'll be glad to provide one. Yoav On 4/18/06, Yonik Seeley [EMAIL PROTECTED] wrote: On 4/18/06, Chris Hostetter [EMAIL PROTECTED] wrote: (or does ServletContext.getServletContextName() not do what I think i remember it doing) Unfortunately not the javadoc says it comes from the web.xml java.lang.String getServletContextName() Returns the name of this web application corresponding to this ServletContext as specified in the deployment descriptor for this web application by the display-name element. -Yonik -- Yoav Shapira Nimalex LLC 1 Mifflin Place, Suite 310 Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com -- Yoav Shapira Nimalex LLC 1 Mifflin Place, Suite 310 Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com
Re: multiple solr webapps
Hola, request, I can find out that someone used the solr1 path to get to me (but that's to late for config type stuff that needs to happen in init()). That but... clause is very important. From what I understand, the Servlet EG discussed this long and hard, many times, over many months, before arriving at the current compromise. There are also other considerations (mod_rewrite comes to mind) that affects this discussion. Anyways, we're not going to change the spec, we're getting off-topic. From my experience supporting Tomcat, approaches relying on the app's context path or disk path are fragile at best. The getResource approaches (either ServletContext or classloader-based) are solid, work well. The JNDI approach is also solid and works well. Other approaches, like having a server-wide config file periodically reloaded and used by all WARs, are also (marginally) OK. None is a zero-configuration approach, but all are fairly close, and easy for both the developer to develop and the server admin to maintain. We could pick one, or we could develop our own thing... Yoav
Initial monthly board report entered
Hi, I've entered an initial blurb for [Lokahi | Solr | OFBiz | log4net] monthly report to the ASF Board at http://wiki.apache.org/incubator/April2006. If you have any comments, suggestions, or changes to make, please go ahead and do so. Thanks, Yoav -- Yoav Shapira Nimalex LLC 1 Mifflin Place, Suite 310 Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com
Re: [jira] Commented: (SOLR-7) can't post queries
The ServletContextListener is better solution. Besides being more elegant and independent of the actual load order of servlets, it has one key advantage. The servlet container is free to destroy and recreate (thus re-initializing) load-on-startup servlets as it sees fit, just the same as any other servlet, so your load-on-startup init code is NOT guaranteed to run just once in the lifetime of the server. Yoav On 4/6/06, Yonik Seeley [EMAIL PROTECTED] wrote: On 4/6/06, Chris Hostetter [EMAIL PROTECTED] wrote: I acctaully thought we were using load-on-startup ... I can't for the life of me figure out why autowarming works since we don't have load-on-startup set to 1. We have it set to 0, meaning it load before 1 (the number is a load order, not true/false) -Yonik -- Yoav Shapira Nimalex LLC 1 Mifflin Place, Suite 310 Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com
Re: Windows/IIS user
Hola, After reviewing solr I am excited about trying it out however I am a windows guy. I am going to try and set up solr using Tomcat/ISAP_Redirector/J2EE AND even try to use the original lucene(java version). Know that although the ISAP_Redirector is a stable and mature piece of software, it's not super-actively maintained. Bugs are fixed and new features added, but only very occassionally. Since I am somewhat new to java as well, could someone give me requirements to develop with solr/lucene for java? For example: is eclipse ok as the development tool and is tomcat the preferred container? You need a JDK, preferably 1.4 and higher. Any Servlet 2.3 compliant container should work, so Tomcat 5.x or later, Jetty 5.x or later, recent (3 years old) versions of WebSphere or Weblogic, all should be fine. I'm biased towards Tomcat as the preferred container, but that's just me ;) Eclipse should also be OK as a development platform, Also, what drawbacks or limitations do you see if I use windows server/IIS with Tomcat/sobr? Drawbacks or limitations compared to what other approach? Yoav -- Yoav Shapira Senior Architect Nimalex LLC 1 Mifflin Place, Suite 310 Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com
Re: forrest version?
Why Forrest? I think it's over-engineered for simple sites. The xdocs approach is so much easier to understand and use on a regular basis. See e.g. http://svn.apache.org/viewcvs.cgi/logging/site/trunk/. Yoav On 1/30/06, Yonik Seeley [EMAIL PROTECTED] wrote: Sigh. When I deleted most of the stuff to get a barebones site, I'm back to the same error. I guess the next step is to build a devel version of forrest and hope it works (or hope for an understandable error message at least). -Yonik On 1/29/06, Yonik Seeley [EMAIL PROTECTED] wrote: What version of forrest are people using to build nutch? I downloaded the prebuilt forrest 0.7, executed forrest.bat in nutch/src/site, and it failed (I used the .bat version, because the normal shell script failed even faster under cygwin). The error: X [0] linkmap.html BROKEN: No pipeline matc hed request: linkmap-linkmap.html Then I tried forrest.bat in forrest's own site-author, and that failed too. Last, I tried forrest.bat seed, then I tried to build that, and it worked! So that's what I'm starting from (and crossing my fingers). -Yonik -- Yoav Shapira System Design and Management Fellow MIT Sloan School of Management Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com
