Will look into this and try and fix it asap.
Getting to know Lucene etc...even bought the Lucene in Action book ! The
Java eco-system never ceases to give you pleasure !
Imtiaz
----- Original Message -----
From: "Ethan Jewett" <[email protected]>
To: <[email protected]>
Sent: Thursday, July 22, 2010 12:21 PM
Subject: Re: Search error when using JDBC for search (was "Metadata
handling")
Not in front of my computer now, so please forgive mistakes.
My testing indicated that in the Compass object in Boot.scala the
conf.buildCompass() method call was failing silently during the setup
of the object.
The exception then occurs later on when the system attempts to use the
Compass.compass value, which I believe was never populated.
So, the actual failure occurs in the SearchMgr object, I think, so it
has Lift methods in the stack trace, but I don't think it's a Lift
issue. I'm not sure why we don't see an exception bubble up from the
buildCompass() method.
That is unfortunately about as far as far as I got.
Ethan
On Thursday, July 22, 2010, Imtiaz Ahmed H E <[email protected]> wrote:
I mean, is this a compass thing ? but why is the exception name not
printed in the log...
----- Original Message ----- From: "Imtiaz Ahmed H E"
<[email protected]>
To: <[email protected]>
Sent: Thursday, July 22, 2010 11:39 AM
Subject: Re: Search error when using JDBC for search (was "Metadata
handling")
So that I can take a quick step forward, can you tell me, how is the
following trace produced...is this a slf4j produced log message.
Andwhy is the exception name itself, I mean , what it is, not printed
along with the stack trace, how can I get it printed.
Enclosing the entire for expression in the 'search' method in
Message.scala in a try/catch expression doesn't seem to result in the
exception being caught by it. Apparently caught earlier, how ? Is this a
Lift thing...?
ERROR - Array(org.apache.esme.model.Message$.search(Message.scala:152),
org.apac
he.esme.lib.SearchMgr$$anonfun$displaySearch$1$$anonfun$apply$1.apply(SearchMgr.
scala:69),
org.apache.esme.lib.SearchMgr$$anonfun$displaySearch$1$$anonfun$apply
$1.apply(SearchMgr.scala:66), net.liftweb.common.Full.map(Box.scala:398),
org.ap
ache.esme.lib.SearchMgr$$anonfun$displaySearch$1.apply(SearchMgr.scala:66),
org.
apache.esme.lib.SearchMgr$$anonfun$displaySearch$1.apply(SearchMgr.scala:65),
ne
----- Original Message ----- From: "Ethan Jewett" <[email protected]>
To: <[email protected]>
Sent: Wednesday, July 21, 2010 8:43 PM
Subject: Search error when using JDBC for search (was "Metadata handling")
To recreate the problem,
1. Replace the contents of /src/main/resources/props/compass.cfg.xml
with the contents of /src/main/resources/props/compass.jndi.cfg.xml
2. mvn jetty:run
3. Point your web browser to http://localhost:8080
4. Log in if necessary
5. Do a search (it won't work and will just redirect you back to the main
page)
6. You should now have a stack trace on the console
Ethan
On Wed, Jul 21, 2010 at 4:48 PM, Imtiaz Ahmed H E <[email protected]>
wrote:
<<<<<<<<<<<<
You don't happen to have any JDBC/JNDI and/or Lucene experience do
you? I'm totally stumped on the issue with search when we have it run
using the database instead of the filesystem (ESME-205).
No, no experience on those. Except have used JDBC for JavaDB access, in my
last job and less than that of it with Oracle 8 years back.
I just tried out a search which had a result of one match, on my system,
and
it worked fine with no exceptions.
If I could reproduce the bug, I could comment on whether I should be
assigned the Jira ticket...saw the exception trace in the ticket, 205, and
the exception seems like a Scala coding problem...
Imtiaz
----- Original Message ----- From: "Ethan Jewett" <[email protected]>
To: <[email protected]>
Sent: Wednesday, July 21, 2010 7:51 PM
Subject: Re: Metadata handling (was "Release planning")
Sounds good to me, at least until we can figure out what the next
step/problem is on the metadata front. Just ping the list when you've
uploaded the patch.
You don't happen to have any JDBC/JNDI and/or Lucene experien