Hey Sean,

Ya I'd expect query_tool to work in this case and filemgr-client with CLI to 
not because the query_tool script reads in its argument differently than 
filemgr-client script... Just a sucky shell side-affect... maybe we can change 
the filemgr-client script to read arguments the same way?... and if I remember 
correctly query_tool isn't perfect either... I think there are causes which 
break query_tool as well... basically the only for sure way to get them to work 
flawlessly is to put the query into a script itself... It has something to do 
with the way the shell parses arguments on the command line and then get 
reparsed by java... i think what happens is the shell is parsing the command 
line query argument as one arg and then passes it to java without quotes so 
java then is parsing the query as a bunch of different args

-Brian 

On Feb 24, 2012, at 8:37 PM, "Hardman, Sean H (388J)" 
<sean.h.hard...@jpl.nasa.gov> wrote:

> Hey Brian,
> 
> I definitely agree with you, something is being expanded or replaced but
> like Chris eluded to, I think it has something to do with the environment.
> I am using Bourne shell in OS X which is the environment where I
> discovered the problem related to [1]. It looks to me to be a similar
> issue although the actual the resulting error is different.
> 
> Ricky, I have seen the same behavior in query_tool. Since Sheryl replied
> while I was typing this response, I have also seen the same behavior.
> 
> Sean
> 
> [1] https://issues.apache.org/jira/browse/OODT-185
> 
> On 2/23/12 2:32 PM, "Nguyen, Ricky" <rngu...@chla.usc.edu> wrote:
> 
>> I've run into this issue with using filemgr-client CLI. I think when the
>> WHERE clause is empty or missing, the parser is trying to send NULL
>> values (as the search criteria) over xmlrpc.
>> 
>> Query tool appears to work with "SELECT * FROM MyProductType"
>> 
>> -Ricky
>> 
>> 
>> On Feb 23, 2012, at 1:29 PM, holenoter wrote:
>> 
>> hey sean,
>> 
>> this part of your log output tells me your shell is expanding your *'s:
>> 
>>>>>> WARNING: XMLRepositoryManager: Unable to find product type:
>>>>>> [convert_map
>>>>>> filemgr filemgr-client migrate_xml_policy query_tool], returning null
>> 
>> -brian
>> 
>> On Feb 23, 2012, at 01:16 PM, "Hardman, Sean H (388J)"
>> <sean.h.hard...@jpl.nasa.gov<mailto:sean.h.hard...@jpl.nasa.gov>> wrote:
>> 
>> Hey Brian,
>> 
>> Restoring to the original filemgr-client script (using $* instead of
>> "$@"), I get the same result with single or double quotes.
>> 
>> Sean
>> 
>> On 2/23/12 11:47 AM, "Brian Foster"
>> <holeno...@me.com<mailto:holeno...@me.com>> wrote:
>> 
>>> Hey Sean,
>>> 
>>> Maybe try using single quotes instead of double... i.e. ... -query
>>> 'SELECT * FROM *'... your shell is prob expanding your *'s
>>> 
>>> -Brian
>>> 
>>> "Hardman, Sean H (388J)"
>>> <sean.h.hard...@jpl.nasa.gov<mailto:sean.h.hard...@jpl.nasa.gov>> wrote:
>>> 
>>>> Hey Chris,
>>>> 
>>>> I would love to prove that theory correct but I am not using variables
>>>> to
>>>> specify my policy directories. I am using absolute paths. Your reply did
>>>> prompt me to run through the tests again and I did discover something in
>>>> the filemgr-client script. In April of last year, I created an issue [1]
>>>> regarding the query_tool script and its lack of support for quoted
>>>> parameters. The resolution was to replace $* in the script with "$@".
>>>> Now
>>>> that the filemgr-client script needs to support the same arguments that
>>>> the query_tool script supports, I am thinking it needs the same patch as
>>>> well. I made that change locally and although the query still fails as
>>>> documented in [2], the error below that you reference no longer is
>>>> generated by the server. I am not entirely clear on the connection
>>>> between
>>>> this patch and the original error (maybe you or Brian could enlighten
>>>> me),
>>>> but it does appear worthy of a new JIRA issue.
>>>> 
>>>> Sean
>>>> 
>>>> [1] https://issues.apache.org/jira/browse/OODT-185
>>>> [2] https://issues.apache.org/jira/browse/OODT-384
>>>> 
>>>> On 2/23/12 6:21 AM, "Mattmann, Chris A (388J)"
>>>> <chris.a.mattm...@jpl.nasa.gov<mailto:chris.a.mattm...@jpl.nasa.gov>>
>>>> wrote:
>>>> 
>>>>> Hey Sean,
>>>>> 
>>>>> Thanks, the below helped, as I think I know now what your problem is.
>>>>> Fast forward to here:
>>>>> 
>>>>> On Feb 21, 2012, at 11:01 AM, Hardman, Sean H (388J) wrote:
>>>>>> 
>>>>>> And generates the following on the server side:
>>>>>> 
>>>>>> Feb 21, 2012 9:32:29 AM
>>>>>> org.apache.oodt.cas.filemgr.repository.XMLRepositoryManager
>>>>>> getProductTypeByName
>>>>>> WARNING: XMLRepositoryManager: Unable to find product type:
>>>>>> [convert_map
>>>>>> filemgr filemgr-client migrate_xml_policy query_tool], returning null
>>>>>> java.lang.NullPointerException
>>>>> 
>>>>> This looks like an incorrect ENV var issue, where you assumed in your
>>>>> product type policy that a particular environment variable was present
>>>>> when you started file manager, but in the end, it wasn't and you
>>>>> defaulted
>>>>> to the current directory (which looks like bin) where you started file
>>>>> manager
>>>>> from as your policy directory.
>>>>> 
>>>>> Can you please confirm that your product type repository path for these
>>>>> three references an environment variable that is actually present when
>>>>> you
>>>>> started the file manager? One way to do this is to simply make sure
>>>>> it's
>>>>> there
>>>>> explicitly in the session (via export or setenv) and then /filemgr
>>>>> restart.
>>>>> 
>>>>> HTH,
>>>>> Chris
>>>>> 
>>>>>> 
>>>>>> On 2/20/12 11:45 PM, "Brian Foster"
>>>>>> <holeno...@me.com<mailto:holeno...@me.com>> wrote:
>>>>>> 
>>>>>>> Hey Sean,
>>>>>>> 
>>>>>>> Try using the new SqlQuery action in 0.4 filemgr
>>>>>>> 
>>>>>>> -Brian
>>>>>>> 
>>>>>>> On Feb 20, 2012, at 6:30 PM, "Hardman, Sean H (388J)"
>>>>>>> <sean.h.hard...@jpl.nasa.gov<mailto:sean.h.hard...@jpl.nasa.gov>>
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> I first noticed this behavior in release 0.3 and just reaffirmed it
>>>>>>>> in
>>>>>>>> a latest and greatest build of 0.4-SNAPSHOT. To the best of my
>>>>>>>> knowledge, this was not the case in previous versions. When
>>>>>>>> querying a
>>>>>>>> File Manager instance with a Lucene Catalog on the back end, the
>>>>>>>> query_tool will throw an exception unless there is a product
>>>>>>>> ingested
>>>>>>>> for each product type listed in the policy (see the stack trace
>>>>>>>> below).
>>>>>>>> 
>>>>>>>> I assume I am not the first person to notice this behavior. Is this
>>>>>>>> worthy of a JIRA issue?
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> Sean
>>>>>>>> 
>>>>>>>> 
>>>>>>>> bash-3.2$ ./query_tool --url ${FILEMGR_URL} --sql -query "SELECT *
>>>>>>>> FROM
>>>>>>>> *"
>>>>>>>> Feb 20, 2012 5:52:26 PM
>>>>>>>> org.apache.oodt.cas.filemgr.catalog.LuceneCatalog paginateQuery
>>>>>>>> WARNING: Query: [q=] for Product Type: [urn:pds:CatalogObject]
>>>>>>>> returned
>>>>>>>> no results
>>>>>>>> java.lang.NullPointerException
>>>>>>>> at
>>>>>>>> 
>>>>>>>> org.apache.oodtcas.filemgr.system.XmlRpcFileManager.complexQuery(Xml
>>>>>>>> Rp
>>>>>>>> cF
>>>>>>>> ileManager.java:602)
>>>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>>>>> at
>>>>>>>> 
>>>>>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl
>>>>>>>> .
>>>>>>>> ja
>>>>>>>> va
>>>>>>>> :39)
>>>>>>>> at
>>>>>>>> 
>>>>>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcce
>>>>>>>> s
>>>>>>>> so
>>>>>>>> rI
>>>>>>>> mpl.java:25)
>>>>>>>> at java.lang.reflect.Method.invoke(Method.java:597)
>>>>>>>> at org.apache.xmlrpc.Invoker.execute(Invoker.java:130)
>>>>>>>> at
>>>>>>>> org.apache.xmlrpc.XmlRpcWorker.invokeHandler(XmlRpcWorker.java:84)
>>>>>>>> at org.apache.xmlrpc.XmlRpcWorker.execute(XmlRpcWorker.java:146)
>>>>>>>> at org.apache.xmlrpc.XmlRpcServer.execute(XmlRpcServer.java:139)
>>>>>>>> at org.apache.xmlrpc.XmlRpcServer.execute(XmlRpcServer.java:125)
>>>>>>>> at org.apache.xmlrpc.WebServer$Connection.run(WebServer.java:761)
>>>>>>>> at org.apache.xmlrpc.WebServer$Runner.run(WebServer.java:642)
>>>>>>>> at javalang.Thread.run(Thread.java:680)
>>>>>>>> org.apache.xmlrpc.XmlRpcException: java.lang.Exception:
>>>>>>>> org.apache.oodt.cas.filemgr.structs.exceptions.CatalogException:
>>>>>>>> Failed
>>>>>>>> to perform complex query : null
>>>>>>>> at
>>>>>>>> 
>>>>>>>> org.apache.xmlrpc.XmlRpcClientResponseProcessor.decodeException(XmlR
>>>>>>>> p
>>>>>>>> cC
>>>>>>>> li
>>>>>>>> entResponseProcessor.java:104)
>>>>>>>> at
>>>>>>>> 
>>>>>>>> org.apache.xmlrpc.XmlRpcClientResponseProcessor.decodeResponse(XmlRp
>>>>>>>> c
>>>>>>>> Cl
>>>>>>>> ie
>>>>>>>> ntResponseProcessor.java:71)
>>>>>>>> at
>>>>>>>> 
>>>>>>>> org.apache.xmlrpc.XmlRpcClientWorker.execute(XmlRpcClientWorker.java
>>>>>>>> :
>>>>>>>> 73
>>>>>>>> )
>>>>>>>> at org.apache.xmlrpc.XmlRpcClient.execute(XmlRpcClient.java:194)
>>>>>>>> at org.apache.xmlrpc.XmlRpcClient.execute(XmlRpcClient.java:185)
>>>>>>>> at org.apache.xmlrpc.XmlRpcClient.execute(XmlRpcClient.java:178)
>>>>>>>> at
>>>>>>>> 
>>>>>>>> org.apache.oodt.cas.filemgr.system.XmlRpcFileManagerClient.complexQu
>>>>>>>> e
>>>>>>>> ry
>>>>>>>> (X
>>>>>>>> mlRpcFileManagerClient.java:974)
>>>>>>>> at
>>>>>>>> 
>>>>>>>> org.apache.oodt.cas.filemgr.tools.QueryTool.performSqlQuery(QueryToo
>>>>>>>> l
>>>>>>>> .j
>>>>>>>> av
>>>>>>>> a:252)
>>>>>>>> at
>>>>>>>> org.apache.oodt.cas.filemgr.tools.QueryTool.main(QueryTool.java:242)
>>>>>>>> Exception in thread "main"
>>>>>>>> org.apache.oodt.cas.filemgr.structs.exceptions.CatalogException:
>>>>>>>> java.lang.Exception:
>>>>>>>> org.apache.oodt.cas.filemgr.structs.exceptions.CatalogException:
>>>>>>>> Failed
>>>>>>>> to perform complex query : null
>>>>>>>> at
>>>>>>>> 
>>>>>>>> org.apache.oodt.cas.filemgr.system.XmlRpcFileManagerClient.complexQu
>>>>>>>> e
>>>>>>>> ry
>>>>>>>> (X
>>>>>>>> mlRpcFileManagerClient.java:980)
>>>>>>>> at
>>>>>>>> 
>>>>>>>> org.apache.oodt.cas.filemgr.tools.QueryTool.performSqlQuery(QueryToo
>>>>>>>> l
>>>>>>>> .j
>>>>>>>> av
>>>>>>>> a:252)
>>>>>>>> at
>>>>>>>> org.apache.oodt.cas.filemgr.tools.QueryTool.main(QueryTool.java:242)
>>>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>> Chris Mattmann, Ph.D.
>>>>> Senior Computer Scientist
>>>>> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>>>>> Office: 171-266B, Mailstop: 171-246
>>>>> Email: chris.a.mattm...@nasa.gov<mailto:chris.a.mattm...@nasa.gov>
>>>>> WWW: http://sunset.usc.edu/~mattmann/
>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>> Adjunct Assistant Professor, Computer Science Department
>>>>> University of Southern California, Los Angeles, CA 90089 USA
>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>> 
>>>> 
>> 
>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments,
>> is for the sole use of the intended recipient(s) and may contain
>> confidential
>> or legally privileged information. Any unauthorized review, use,
>> disclosure
>> or distribution is prohibited. If you are not the intended recipient,
>> please
>> contact the sender by reply e-mail and destroy all copies of this
>> original message. 
>> 
>> ---------------------------------------------------------------------
>> 
> 

Reply via email to