Mailing-List: contact esme-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: esme-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of hirsch.dick@gmail.com
 designates 209.85.215.47 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=u2Vm01xck+FXQ0VI8e5BxZP8kY7fz97SYqtOzdDHuaenxd5B16fe6RULV/Hrc8qAhS
         yweNUZ7POzFBq5eGlnmeSkTZR2Xw5wGJyhfPQlYyufVi/RCv5plJZYUy3m0khB9DXX8W
         1mFdtMhEa2pJrD2jVQbCEn/QyXPc5J0k/YJs8=
MIME-Version: 1.0
In-Reply-To: <BB5D5771D70648439936057224A130CF@imtiaz20100131>
References: <5732C36264DE4025868DAD5733027510@imtiaz20100131>
	<AANLkTim5NH1mCmDnM5mykBhoYZyn5DiXt9G7nFvh-2Kc@mail.gmail.com>
	<50BF7B0DD0AF471F807AA1326364F792@imtiaz20100131>
	<AANLkTinncMC_H_pKANLU1O-kTeTxTfiZK5_JFyqGQzE2@mail.gmail.com>
	<AANLkTimYjH8t6sT6OENUC=UGfR9_BrxLMUZATz9gdgWM@mail.gmail.com>
	<BB5D5771D70648439936057224A130CF@imtiaz20100131>
Date: Sun, 1 Aug 2010 16:03:40 -0700
Message-ID: <AANLkTin-qOEc=mb65HD3jguPaVsoL9UQ2kPYk0Wqha=s@mail.gmail.com>
Subject: Re: Search error when using JDBC for search (was "Metadata handling")
From: Richard Hirsch <hirsch.dick@gmail.com>
To: esme-dev@incubator.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I'm checking my email at about the half way point of my vacation.

You can duplicate the problem by attempting to use the JDBC driver
locally - just copy the JDBC details from Boot.scala.

The search results should be the same irregardless of whether you use
file or JDBC.  I'm assuming that problem is associated more with the
use of JBC in compass - ideally you could add better exception
handling in Boot.scala. I'm assuming the jdbc-related problem alreadz
occurs during start-up but just isn't displayed.

On Sat, Jul 31, 2010 at 6:51 AM, Imtiaz Ahmed H E <in.imtiaz@gmail.com> wro=
te:
> Ethan or anyone else,
>
> I have a checkout of ESME readonly without local modifications and search=
 in
> the non-jdbc/non-jndi case itself *appears* to be not working on my syste=
m (
> i.e., in the file system index case!).
>
> I think I'm not searching for a term that actually exists.
>
> So, a basic question,
>
> If I'm logged in and enter a term in the search box and hit return, where=
 is
> esme supposed to search for the term. I don't know till today. Is it
> supposed to look for the term in *all* messages in the db regardless of
> user/pool etc. If not, in which subset is it supposed to look?
>
> Imtiaz
>
> --- Original Message ----- From: "Anne Kathrine Petter=C5=99e"
> <yojibee@gmail.com>
> To: <esme-dev@incubator.apache.org>
> Sent: Friday, July 30, 2010 3:24 PM
> Subject: Re: Search error when using JDBC for search (was "Metadata
> handling")
>
>
>> Hi,
>>
>> I am sorry but I cannot help out here either.
>>
>> Anne
>>
>>
>> On 30 July 2010 09:59, Ethan Jewett <esjewett@gmail.com> wrote:
>>
>>> Hi Imtiaz,
>>>
>>> Unfortunately I do not know the answer to either of those questions
>>> :-( I think we'll have to wait for Dick to give us more info on how he
>>> does the Stax deployment and what worked before.
>>>
>>> Ethan
>>>
>>> On Friday, July 30, 2010, Imtiaz Ahmed H E <in.imtiaz@gmail.com> wrote:
>>> > Ethan,
>>> >
>>> > Couple of questions:
>>> >
>>> > 1. I'm not familiar with the Stax environment, so I wondered if Esme =
>
>>> > used
>>> Derby (JavaDB) there too for the Esme store (nothing to do with search,
>>> this
>>> question).
>>> >
>>> > 2. Re search, is it/was it ever working with just jdbc not jndi. i.e,
>>> with the setup of the compass config file, compass.jdbc.cfg.xml.
>>> > I guess your answer will be the same as in your mail below...
>>> >
>>> > Imtiaz
>>> >
>>> >
>>> > ----- Original Message ----- From: "Ethan Jewett" <esjewett@gmail.com=
>
>>> > To: <esme-dev@incubator.apache.org>
>>> > Sent: Thursday, July 29, 2010 5:28 PM
>>> > Subject: Re: Search error when using JDBC for search (was "Metadata
>>> handling")
>>> >
>>> >
>>> >
>>> > Hi Imtiaz,
>>> >
>>> > Hopefully Dick will see this and answer at some point, because he
>>> > really knows. But I do believe that it was working on Stax using the
>>> > JDBC connector and then stopped working. Stax has never allowed us to
>>> > use the file system, so if it was ever working on Stax then it was
>>> > using the JDBC connector.
>>> >
>>> > Thanks,
>>> > Ethan
>>> >
>>> > On Thu, Jul 29, 2010 at 1:39 PM, Imtiaz Ahmed H E <in.imtiaz@gmail.co=
m>
>>> wrote:
>>> >
>>> > Ethan,
>>> >
>>> > Need to know -
>>> >
>>> > Re ESME-205, viz, Search is Broken....
>>> >
>>> > Has this been implemented in the first place, with jndi/jdbc I mean..=
.?
>>> And
>>> > if it was, was it ever working ?
>>> >
>>> > Just getting into all the related stuff along with Lucene...
>>> >
>>> > Imtiaz
>>> >
>>> > ----- Original Message ----- From: "Imtiaz Ahmed H E" <
>>> in.imtiaz@gmail.com>
>>> > To: <esme-dev@incubator.apache.org>
>>> > Sent: Monday, July 26, 2010 5:03 AM
>>> > Subject: Re: Search error when using JDBC for search (was "Metadata
>>> > handling")
>>> >
>>> >
>>> >
>>> > 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" <esjewett@gmail.com=
>
>>> > To: <esme-dev@incubator.apache.org>
>>> > 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 th=
e
>>> > 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 <in.imtiaz@gmail.com>
>>> 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"
>>> > <in.imtiaz@gmail.com>
>>> > To: <esme-dev@incubator.apache.org>
>>> > 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 thi=
s
>>> > > 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(S=
earchMgr.
>>> > 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.scal=
a:65),
>>> > ne
>>> >
>>> >
>>> > ----- Original Message ----- From: "Ethan Jewett" <esjewett@gmail.com=
>
>>> > To: <esme-dev@incubator.apache.org>
>>> > 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 <in.imtiaz@gmail.co=
m>
>>> > 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" <esjewett@gmail.com=
>
>>> > To: <esme-dev@incubator.apache.org>
>>> > 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
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>>
>>
>
>