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/main/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 |
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Kernel-development mailing list [email protected] http://sesat.no/mailman/listinfo/kernel-development
