incubator-esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Imtiaz Ahmed H E" <in.imt...@gmail.com>
Subject Re: Search error when using JDBC for search (was "Metadata handling")
Date Thu, 22 Jul 2010 06:09:34 GMT
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" <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.com> 
> 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 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).
>>>
>>> Ethan
>>>
>>> On Wed, Jul 21, 2010 at 4:06 PM, Imtiaz Ahmed H E <in.imtiaz@gmail.com>
>>> wrote:
>>>>
>>>> Oops! I think I wrote that in a hurry, not even thinking!!
>>>>
>>>> Actually, I think I should just submit a patch to the metadata branch
>>>> with
>>>> my current change and move on to other Jira tickets while we wait for
>>>> consensus/finalization.
>>>>
>>>> Imtiaz
>>>>
>>>> ----- Original Message ----- From: "Imtiaz Ahmed H E"
>>>> <in.imtiaz@gmail.com>
>>>> To: <esme-dev@incubator.apache.org>
>>>> Sent: Wednesday, July 21, 2010 7:30 PM
>>>> Subject: Re: Metadata handling (was "Release planning")
>>>>
>>>>
>>>>> How about it if I just store the metadata as a literal string and 
>>>>> return
>>>>> it as such for now and submit a patch to the metadata branch with that
>>>>> and
>>>>> move on to another Jira ticket ?
>>>>>
>>>>> Then, when we all agree on something final for the output format and
>>>>> representation of message metadata we can look at further work on
>>>>> ESME-242.
>>>>>
>>>>> Imtiaz
>>>>>
>>>>> ----- Original Message ----- From: "Ethan Jewett" <esjewett@gmail.com>
>>>>> To: <esme-dev@incubator.apache.org>
>>>>> Sent: Wednesday, July 21, 2010 7:01 PM
>>>>> Subject: Re: Metadata handling (was "Release planning")
>>>>>
>>>>>
>>>>> Imtiaz,
>>>>>
>>>>> Excellent! That's good progress.
>>>>>
>>>>> Any idea what the API response is still getting HTML entity-encoded?
>>>>> That's what all of those &lt; and &gt; things are. Does the API
do
>>>>> this for all of its responses or is it just the metadata ones? We
>>>>> probably don't need to be entity-encoding since we're returning XML,
>>>>> not HTML.
>>>>>
>>>>> Also, I just created a branch called "metadata". Can you work against
>>>>> this branch and feel free to submit patches against that branch to the
>>>>> Jira ticket. Vassil, Anne, or I can then apply the patches directly to
>>>>> the branch without the level of review that would be needed for a
>>>>> patch against trunk. This should help allow us to try out your changes
>>>>> and come to consensus and understanding more quickly.
>>>>>
>>>>> Thanks!
>>>>> Ethan
>>>>>
>>>>> On Wed, Jul 21, 2010 at 7:20 AM, Imtiaz Ahmed H E 
>>>>> <in.imtiaz@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> By the way, all I did was,
>>>>>>
>>>>>> in Message.scala,
>>>>>> replace,
>>>>>>
>>>>>> lazy val metadata: String = originalXml \ "metadata" text
>>>>>>
>>>>>> by...
>>>>>>
>>>>>> lazy val metadata: String = (originalXml \ "metadata").toString
>>>>>>
>>>>>> to get the results you see in my previous mail...
>>>>>>
>>>>>> Imtiaz
>>>>>>
>>>>>> ----- Original Message ----- From: "Imtiaz Ahmed H E"
>>>>>> <in.imtiaz@gmail.com>
>>>>>> To: <esme-dev@incubator.apache.org>
>>>>>> Sent: Wednesday, July 21, 2010 10:34 AM
>>>>>> Subject: Re: Metadata handling (was "Release planning")
>>>>>>
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> In the absence of decisive consensus yet, I made a small change
in
>>>>>>> Message.scala as a first step in fixing ESME-242.
>>>>>>> Here's curl output for the Jira ticket examples given there by
>>>>>>> Ethan...There is maybe obvious unacceptable stuff here, but let
me
>>>>>>> know...
>>>>>>>
>>>>>>> imtiaz@imtiaz-20100131 /cygdrive/d/temp
>>>>>>> $ curl --dump-header headers -d
>>>>>>> "token=HEZTQKM525SAMIPN4EDVRUOGHI40AKBL"
>>>>>>> http:/
>>>>>>>
>>>>>>> /localhost:8080/esme-server-apache-esme-1.0-RC1-incubating/api2/session
>>>>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> <api><session><user><id>3</id><nickname>imtiaz2</nickname><image>None</image><wh
>>>>>>> ole_name>I A 2 H E</whole_name></user></session></api>
>>>>>>>
>>>>>>> imtiaz@imtiaz-20100131 /cygdrive/d/temp
>>>>>>> $ cat headers
>>>>>>> HTTP/1.1 200 OK
>>>>>>> Server: Apache-Coyote/1.1
>>>>>>> Set-Cookie: JSESSIONID=C7B688BAF8E99B2A638EF432885E310E;
>>>>>>> Path=/esme-server-apach
>>>>>>> e-esme-1.0-RC1-incubating
>>>>>>> Expires: Wed, 21 Jul 2010 04:56:51 UTC
>>>>>>> Date: Wed, 21 Jul 2010 04:56:51 GMT
>>>>>>> Pragma: no-cache
>>>>>>> Cache-Control: no-cache; private; no-store
>>>>>>> X-Lift-Version: 2.0-SNAPSHOT
>>>>>>> Content-Type: text/xml;charset=utf-8
>>>>>>> Content-Length: 178
>>>>>>>
>>>>>>>
>>>>>>> imtiaz@imtiaz-20100131 /cygdrive/d/temp
>>>>>>> $ curl -b headers -d
>>>>>>> 'message=test200&metadata=<outer><meta><metameta>Hello</me
>>>>>>> tameta></meta><onlymeta>Meta</onlymeta></outer>'
>>>>>>> http://localhost:8080/esme-ser
>>>>>>> ver-apache-esme-1.0-RC1-incubating/api2/user/messages
>>>>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>>>>> <api><message>
>>>>>>> <id>28</id>
>>>>>>> <date>Wed, 21 Jul 2010 04:57:05 UTC</date>
>>>>>>> <source>api2</source>
>>>>>>> <body>test200</body>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> <metadata>&lt;metadata&gt;&lt;outer&gt;&lt;meta&gt;&lt;metameta&gt;Hello&lt;/m
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> etameta&gt;&lt;/meta&gt;&lt;onlymeta&gt;Meta&lt;/onlymeta&gt;&lt;/outer&gt;&lt;/
>>>>>>> metadata&gt;</metadata>
>>>>>>> <author><nickname>imtiaz2</nickname><id>3</id></author>
>>>>>>> <tags></tags><replyto></replyto><conversation></conversation>
>>>>>>> </message></api>
>>>>>>>
>>>>>>> imtiaz@imtiaz-20100131 /cygdrive/d/temp
>>>>>>> $ curl -b headers -d
>>>>>>> 'message=test201&metadata=<anytag>"meta":[{"place":{"place
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _type":"city","region":"CA+"}},{"song":{"artist":"Prince","songtitle":"Never+Le
>>>>>>> t+Me+Down"}}]</anytag>'
>>>>>>> http://localhost:8080/esme-server-apache-esme-1.0-RC1-i
>>>>>>> ncubating/api2/user/messages
>>>>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>>>>> <api><message>
>>>>>>> <id>29</id>
>>>>>>> <date>Wed, 21 Jul 2010 04:57:39 UTC</date>
>>>>>>> <source>api2</source>
>>>>>>> <body>test201</body>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> <metadata>&lt;metadata&gt;&lt;anytag&gt;&amp;quot;meta&amp;quot;:[{&amp;quot;p
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> lace&amp;quot;:{&amp;quot;place_type&amp;quot;:&amp;quot;city&amp;quot;,&amp;quo
>>>>>>> t;region&amp;quot;:&amp;quot;CA
>>>>>>> &amp;quot;}},{&amp;quot;song&amp;quot;:{&amp;quo
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> t;artist&amp;quot;:&amp;quot;Prince&amp;quot;,&amp;quot;songtitle&amp;quot;:&amp
>>>>>>> ;quot;Never Let Me
>>>>>>> Down&amp;quot;}}]&lt;/anytag&gt;&lt;/metadata&gt;</metadata>
>>>>>>>
>>>>>>> <author><nickname>imtiaz2</nickname><id>3</id></author>
>>>>>>> <tags></tags><replyto></replyto><conversation></conversation>
>>>>>>> </message></api>
>>>>>>>
>>>>>>> imtiaz@imtiaz-20100131 /cygdrive/d/temp
>>>>>>> $ curl -b headers -d
>>>>>>> 'message=test202&metadata="meta":[{"place":{"place_type":"
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> city","region":"CA+"}},{"song":{"artist":"Prince","songtitle":"Never+Let+Me+Dow
>>>>>>> n"}}]'
>>>>>>>
>>>>>>> http://localhost:8080/esme-server-apache-esme-1.0-RC1-incubating/api2/us
>>>>>>> er/messages
>>>>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>>>>> <api><message>
>>>>>>> <id>30</id>
>>>>>>> <date>Wed, 21 Jul 2010 04:58:02 UTC</date>
>>>>>>> <source>api2</source>
>>>>>>> <body>test202</body>
>>>>>>> <metadata></metadata>
>>>>>>> <author><nickname>imtiaz2</nickname><id>3</id></author>
>>>>>>> <tags></tags><replyto></replyto><conversation></conversation>
>>>>>>> </message></api>
>>>>>>>
>>>>>>> imtiaz@imtiaz-20100131 /cygdrive/d/temp
>>>>>>> $ curl -b headers
>>>>>>> http://localhost:8080/esme-server-apache-esme-1.0-RC1-incubat
>>>>>>> ing/api2/user/messages
>>>>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>>>>> <api><messages><message>
>>>>>>> <id>30</id>
>>>>>>> <date>Wed, 21 Jul 2010 04:58:02 UTC</date>
>>>>>>> <source>api2</source>
>>>>>>> <body>test202</body>
>>>>>>> <metadata></metadata>
>>>>>>> <author><nickname>imtiaz2</nickname><id>3</id></author>
>>>>>>> <tags></tags><replyto></replyto><conversation></conversation>
>>>>>>> </message><message>
>>>>>>> <id>29</id>
>>>>>>> <date>Wed, 21 Jul 2010 04:57:39 UTC</date>
>>>>>>> <source>api2</source>
>>>>>>> <body>test201</body>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> <metadata>&lt;metadata&gt;&lt;anytag&gt;&amp;quot;meta&amp;quot;:[{&amp;quot;p
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> lace&amp;quot;:{&amp;quot;place_type&amp;quot;:&amp;quot;city&amp;quot;,&amp;quo
>>>>>>> t;region&amp;quot;:&amp;quot;CA
>>>>>>> &amp;quot;}},{&amp;quot;song&amp;quot;:{&amp;quo
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> t;artist&amp;quot;:&amp;quot;Prince&amp;quot;,&amp;quot;songtitle&amp;quot;:&amp
>>>>>>> ;quot;Never Let Me
>>>>>>> Down&amp;quot;}}]&lt;/anytag&gt;&lt;/metadata&gt;</metadata>
>>>>>>>
>>>>>>> <author><nickname>imtiaz2</nickname><id>3</id></author>
>>>>>>> <tags></tags><replyto></replyto><conversation></conversation>
>>>>>>> </message><message>
>>>>>>> <id>28</id>
>>>>>>> <date>Wed, 21 Jul 2010 04:57:05 UTC</date>
>>>>>>> <source>api2</source>
>>>>>>> <body>test200</body>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> <metadata>&lt;metadata&gt;&lt;outer&gt;&lt;meta&gt;&lt;metameta&gt;Hello&lt;/m
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> etameta&gt;&lt;/meta&gt;&lt;onlymeta&gt;Meta&lt;/onlymeta&gt;&lt;/outer&gt;&lt;/
>>>>>>> metadata&gt;</metadata>
>>>>>>> <author><nickname>imtiaz2</nickname><id>3</id></author>
>>>>>>> <tags></tags><replyto></replyto><conversation></conversation>
>>>>>>> </message></messages></api>
>>>>>>>
>>>>>>> imtiaz@imtiaz-20100131 /cygdrive/d/temp
>>>>>>> $
>>>>>>>
>>>>>>> ----- Original Message ----- From: "Vassil Dichev"
>>>>>>> <vdichev@apache.org>
>>>>>>> To: <esme-dev@incubator.apache.org>
>>>>>>> Sent: Tuesday, July 20, 2010 11:27 AM
>>>>>>> Subject: Re: Metadata handling (was "Release planning")
>>>>>>>
>>>>>>>
>>>>>>>>> I'd prefer option 1 (separate attribute from text). Within
this
>>>>>>>>> separate attribute there is the question of how data
is
>>>>>>>>> stored/represented. I'm ok with either raw string or
a tuple-based
>>>>>>>>> structure like Twitter's. I kind of like the tuple (key-value)
>>>>>>>>> approach.
>>>>>>>>
>>>>>>>> I'm not too interested in how the data is stored, because
it's 
>>>>>>>> fairly
>>>>>>>> trivial to implement either way. It's currently not yet clear
to me
>>>>>>>> what the requirements for the output format are.
>>>>>>>>
>>>>>>>>> What I'm insisting on and what I was saying we got wrong
is that
>>>>>>>>> what
>>>>>>>>> goes in needs to be the same as what comes out. If it's

>>>>>>>>> tuple-based
>>>>>>>>> and I send in a tuple, then I should get that tuple (key
and 
>>>>>>>>> value)
>>>>>>>>> back out when I request the metadata for a message. Right
now I
>>>>>>>>> think
>>>>>>>>> we only get a concatenated list of values from the metadata
and
>>>>>>>>> metaData methods and we're bound to an XML format.
>>>>>>>>
>>>>>>>> I don't get it. A tuple is an abstraction which might be
expressed 
>>>>>>>> in
>>>>>>>> a specific format. So what goes in is not what comes out
depending 
>>>>>>>> on
>>>>>>>> the format. Let me quote the specific example Twitter provides.
>>>>>>>>
>>>>>>>> This comes in:
>>>>>>>>
>>>>>>>> "annotations":
>>>>>>>> [{"type":{"another_attribute":"value", "attribute":"value"}}]
>>>>>>>>
>>>>>>>> This comes out:
>>>>>>>>
>>>>>>>> <annotations type="array">
>>>>>>>> <annotation>
>>>>>>>> <type>foo</type>
>>>>>>>> <attributes>
>>>>>>>> <attribute>
>>>>>>>> <name>bar</name>
>>>>>>>> <value>baz</value>
>>>>>>>> </attribute>
>>>>>>>> </attributes>
>>>>>>>> </annotation>
>>>>>>>> </annotations>
>>>>>>>>
>>>>>>>>
>>>>>>>>> As far as requiring a particular format, I think the
internal 
>>>>>>>>> format
>>>>>>>>> should be either a raw string or a immutable hashmap
with raw
>>>>>>>>> strings
>>>>>>>>> as keys and values. We can handle converting this to
XML or JSON 
>>>>>>>>> in
>>>>>>>>> the API or view code.
>>>>>>>>
>>>>>>>> Again, it's not so interesting what's internally there, let's
just
>>>>>>>> treat it as a black box. What I want to know is, do we want
to have
>>>>>>>> for instance XML in a JSON reply returned:
>>>>>>>>
>>>>>>>> "annotations":
>>>>>>>> [{"type":{"<attributes> <attribute> <name>bar</name>
>>>>>>>> <value>baz</value> </attribute> </attributes>"}}]
>>>>>>>>
>>>>>>>> or, inversely, do we want JSON inside an XML reply? Something
like:
>>>>>>>>
>>>>>>>> <annotations type="array">
>>>>>>>> <annotation>
>>>>>>>> <type>foo</type>
>>>>>>>> <attributes>
>>>>>>>> {"another_attribute":"value", "attribute":"value"}
>>>>>>>> </attributes>
>>>>>>>> </annotation>
>>>>>>>> </annotations>
>>>>>>>>
>>>>>>>> because the latter will need to be escaped.
>>>>>>>>
>>>>>>>> Sorry for being too dense, but in any case, we either have
to 
>>>>>>>> escape
>>>>>>>> the metadata or we have to transform the structure to XML/JSON
when
>>>>>>>> we
>>>>>>>> return it back to the user. None of these is "what goes in
needs to
>>>>>>>> be
>>>>>>>> the same as what comes out"
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>
>> 


Mime
View raw message