Mck, Thanks! I am now using the 2.18 branch, but when using the same modes and views that I sent earlier, I am still getting:
ERROR 23:02:00,578 [localhost.com:8080/ http-8080-1] (b890115d-48fc-46b2-801a-8c6de6351013) SiteLocatorFilter: Unable to construct AbstractEvaluatorFactory: no.sesat.search.query.token.SolrEvaluatorFactory java.lang.IllegalArgumentException: Unable to construct AbstractEvaluatorFactory: no.sesat.search.query.token.SolrEvaluatorFactory on first load of localhost.com. Could you help me understand why? I have also attached the new command and config classes my modes.xml refers to. Thanks! Brian Frutchey Federal Solutions Architect M (703) 597-4875 E [email protected] Endeca 2100 Reston Parkway Ste 101 Reston, VA 20171 www.endeca.com find / analyze / understand -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Mck Sent: Tuesday, August 11, 2009 1:54 PM To: [email protected] Subject: Re: Sesat startup feedback Thanks for the input Brian. I've added some of this into the upstream documentation already! But we haven't got the autoexport from confluence to sesat's website working properly again so it'll take time before you see your own words there :-) > I checked out the sesat-kernal trunk (2.19-SNAPSHOT I believe) Trunk is ... well ... trunk. 2.18 is the current "stable" branch. (It too is currently under a bit of development while sesat-user is in development against it -don't ask while this isn't happening in trunk...- but it definitely going to be more stable than trunk). > - needs a 1.6JDK, not just JRE Correct. Is this not clear in the documentation? It says so in the "Requirements" page off "Getting Started". I'm open to suggestions for improvements. > - run with tests disabled : mvn -Dmavin.test.skip -e install Correct. Especially on windows due to file path references when loading skin resources Furthermore these tests have been much neglected recently. mea maxima culpa. > - localhost.com has a bad SearchPortal.tld file, it needs to be > overwritten with the same file from the ROOT context (and fixed in > maven...) Yes, it's a symlink that won't work as is on windows. Not the best practice i know, but i've updated the documentation to make this clearer. In fact it's not needed at runtime, but most IDEs will complain and marked JSPs full of errors if it's not there. > - sesat-user-api missing from ROOT.war, need to change dependency to > config scope in top-level pom This is already in the upstream documentation and waiting for autoexport to be fixed. >From the upstream docs; *sesat-user-api* This must be manually deployed. Since it is a jar file in JBoss it can be directly deployed as is. In Tomcat it must be copied into the tomcat's lib directory. > - default generic.sesam and localhost.com seem preset for someone's dev env. I had to comment out: > > <!-- <include key="head-element-extra" template="sesam.com/mwsuggest.jsp"/> --> > <!-- <include key="no-hits" template="sesam.com/no-hits.jsp"/> --> > > in the localhost.com views.xml as these fragments don't exist in the trunk, and the modes.xml I see the latter template in trunk: http://sesat.no/svn/sesat-kernel/trunk/generic.sesam/sesam.com/war/src/m ain/webapp/WEB-INF/classes/fragments/layout/sesam.com/no-hits.jsp But mwsuggest.jsp was only in 2.18! A failed 2.18 to trunk merge. It's fixed now. But, like in the sesam.com tutorial, you don't need it so leave it commented out. > for both generic.sesam and localhost.com seem to have many proprietary > servers referenced. Yes. These are intended solely as examples. But it's intended that these example reference search commands do not get in your way in your own skin. Sesat-kernel is such a big body of work with development pushed by both commercial needs and personal itches. There hasn't been enough time to document everything so these references are but a poor intermediate solution. So far documentation beyond the "Upgrade Guides" (which we're been quite strict with) has written mostly with curiosity/demand shown from posters such as yourself. > Even after overwriting the localhost.com modes and > configuration.properties with the suggestions from > http://sesat.no/tutorial-building-sesamcom.html, the localhost.com > initial search page loads, but once a search is executed the > exception: > ... > Caused by: java.lang.IllegalAccessError: tried to access method > no.sesat.search.mode.command.AbstractSearchCommand.getFilter()Ljava/lang /String; from class no.sesat.search.mode.command.YahooWebSearchCommand$1 Right. Fixed in 2.18 and merged into trunk. > # TODO rename to default_remote_service_url > schibstedsok_remote_service_url=localhost:1099 > user_service_jndi_name=sesat-user/BasicUserService/remote > > which actually causes exceptions to be logged at the "info" level in > the sesat.log - this is worrisome to a newbie reviewing the log for > the first time. Can I essentially delete everything in generic.sesam > to avoid extra processing being done? Yes. The whole sesat-user-api is under heavy development at the moment. The property key names will be cleaned up to use more generic names. In the meantime you can disabled it by adding to your configuration.properties sesat.userservice.enabled=false > I also tried just visiting http://generic.sesam:8080 as a stand-alone > skin, and got this exception: > > ERROR 01:59:31,671 [generic.sesam:8080/ http-8080-10] > (231aca34-c430-4c0e-8e33-74dfc2775965) VelocityEngineFactory: Resource > not available: > http://generic.sesam:8080/generic.sesam/templates/VM_global_library.vm > > org.apache.velocity.exception.ResourceNotFoundException: Cannot find > resource > Again, probably something needs to be commented out, but another point > of frustration. I see your frustrations, i'll promise to keep helping you the best i can. The skins can't be browsed, there's a number of security measures inside ResourceServlet - the servlet responsible for serving all the resource files inside each skin. To test the skin: request directly the configuration.properties file (which every skin must have). eg http://generic.sesam:8080/generic.sesam/conf/configuration.properties > Also, please help me understand something - Is the architecture here > to organize skins hierarchically so that children skins will also > receive results from the services configured in their parent skins? > If this is so, why? Yes. But only commands explicitly added to each mode will actually be executed. The benefit is you can configure the commands and all their parameters in just one in a base mode and/or skin. And then have multiple skins all inheriting these settings. History behind this is sesam.no and sesam.se were running all within the one jvm many sitesearches for various commercial partners around norway and sweden. They basically all had the same search commands with small differences, and different visual templates of course. So "sesam.no" and "sesam.se" were are base skins and with the many sitesearch websites as child skins. There's a second added benefit: it becomes very easy to test an unlimited amount of alternative back tiers (indexes) with matching child skins by simply overriding the the server urls in configuration.properties in each child skin. For example http://stage.sesam.com could be the same middle "java" tier (and is in fact the very same java application) as http://sesam.com but searches are executed instead against a "dev" back tier. ~mck -- "No matter how hard the past,you can always begin again." Buddha | semb.wever.org | sesat.no | finn.no |
EndecaSearchCommand.java
Description: EndecaSearchCommand.java
EndecaCommandConfig.java
Description: EndecaCommandConfig.java
_______________________________________________ Kernel-development mailing list [email protected] http://sesat.no/mailman/listinfo/kernel-development
