I have been succescully using a 'nightly build' from a week ago.  I updated
to the trunk version and am unable to get the example webapp to deploy.

I get an error that says "Schema Parsing Failed" caused by
NumberFormatException when trying to set the version in
IndexSchema.readConfig().

I was able to get the schema to load (and still pass all the tests) by
modifying org.apache.solr.core.Config.getVal( ... )

- - -

trunk:
  String txt = DOMUtil.getText(nd);

mine:

  String txt = DOMUtil.getText(nd);
  if( txt == null || txt.length() < 1 ) {
      txt = nd.getNodeValue();
  }

- - - -

I'm not sure this i a 'real' fix, as i don't fully understand it.  any
thougts what may be going on?  Are other people having this problem?

thanks
ryan

On 12/21/06, ryan mckinley <[EMAIL PROTECTED]> wrote:
> I have been succescully using a 'nightly build' from a week ago.  I updated
> to the trunk version and am unable to get the example webapp to deploy.

Are you using Jetty as the container, or some other servlet container?
It sounds like a problem with XML parser compatibility problem.

There was recent related patch:
http://issues.apache.org/jira/browse/SOLR-78

-Yonik

I'm running resin-3.0.21

I applied the path from SOLR-78. This fixed this issue when i am
running on windows, but strangely, it is still there on the linux
version!

For now, i guess i just have to keep in the:

  if( txt == null || txt.length() < 1 ) {
    txt = nd.getNodeValue();
  }

but that seems wrong...
On 12/21/06, Yonik Seeley <[EMAIL PROTECTED]> wrote:
> On 12/21/06, ryan mckinley <[EMAIL PROTECTED]> wrote:
> > I have been succescully using a 'nightly build' from a week ago.  I updated
> > to the trunk version and am unable to get the example webapp to deploy.
>
> Are you using Jetty as the container, or some other servlet container?
> It sounds like a problem with XML parser compatibility problem.
>
> There was recent related patch:
> http://issues.apache.org/jira/browse/SOLR-78
>
> -Yonik
>

Ryan: the relevant functionality is highly dependent on which DOM parser
the user has ... that was the goal of SOLR-78, to make Solr work for
people who only have a DOM Level 2 parser.

I'm a little confused by two things...

1) can you please post the stack trace from the "Schema Parsing Failed"
SolrException you got when using the trunk ... i'd like to try and figure
out which "number" from the schema it had a problem parsing based on the
line numbers from the stack trace

2) what exactly do you mean by...

: I applied the path from SOLR-78. This fixed this issue when i am
: running on windows, but strangely, it is still there on the linux
: version!

...there are two patches in SOLR-78, the first is 4k dated 14/Dec, the
second is 3k labeled 7/Dec (the labels show up when you mouse over the
links).  the 4K version is already commited in the trunk.  Are you saying
that when you used the older version of the patch, the problem went away
in windows?

: For now, i guess i just have to keep in the:
:
:   if( txt == null || txt.length() < 1 ) {
:     txt = nd.getNodeValue();
:   }
hmmm.... I'm having troubling figuring out any way that the current
DOMUtil.getText would return null or the empty string if nd.getNodeValue
acctually has something usefull in it.

-Hoss

I have the trunk version with patch #1 on SOLR-78 (the one edited at
11:59am).  When i run the war file on a windows machine running
resin-3.0.21 it works fine.  When i run it on a linux box (debian)
also running resin-3.0.21, i get:

I get:

[00:25:35.025] Caused by: java.lang.NumberFormatException: empty String
[00:25:35.025]  at
sun.misc.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:994)
[00:25:35.025]  at java.lang.Float.parseFloat(Float.java:394)
[00:25:35.025]  at org.apache.solr.core.Config.getFloat(Config.java:174)
[00:25:35.025]  at
org.apache.solr.schema.IndexSchema.readConfig(IndexSchema.java:273)

- - - - - - - -

Here is the whole stack trace:
[00:25:33.550] expanding /home/lapnap/solr/webapp/solr.war to
/home/lapnap/solr/webapp/solr
[00:25:34.147] WebApp[http://localhost:8765/solr] starting
[00:25:34.211] SolrServer: init
[00:25:34.212] SolrServlet.init()
[00:25:34.231] Solr home set to '/home/lapnap/solr/'
[00:25:34.232] user.dir=/usr/local/resin-3.0.21
[00:25:34.367] Loaded SolrConfig: solrconfig.xml
[00:25:34.630] adding requestHandler standard=solr.StandardRequestHandler
[00:25:34.641] Adding 'file:/home/lapnap/solr/lib/.svn/' to Solr classloader
[00:25:34.642] Adding
'file:/home/lapnap/solr/lib/commons-codec-1.3.jar' to Solr classloader
[00:25:34.642] Adding 'file:/home/lapnap/solr/lib/commons-lang.jar' to
Solr classloader
[00:25:34.643] Adding 'file:/home/lapnap/solr/lib/solrex.jar' to Solr
classloader
[00:25:34.721] adding requestHandler dismax=solr.DisMaxRequestHandler
[00:25:34.831] adding requestHandler partitioned=solr.DisMaxRequestHandler
[00:25:34.856] adding requestHandler instock=solr.DisMaxRequestHandler
[00:25:34.932] Opening new SolrCore at /home/lapnap/solr/,
dataDir=/home/lapnap/solr/data
[00:25:34.964] Reading Solr Schema
[00:25:34.997] Schema name=example
[00:25:35.012] org.apache.solr.core.SolrException: Schema Parsing Failed
[00:25:35.012]  at
org.apache.solr.schema.IndexSchema.readConfig(IndexSchema.java:441)
[00:25:35.012]  at
org.apache.solr.schema.IndexSchema.<init>(IndexSchema.java:69)
[00:25:35.012]  at org.apache.solr.core.SolrCore.<init>(SolrCore.java:191)
[00:25:35.012]  at org.apache.solr.core.SolrCore.getSolrCore(SolrCore.java:172)
[00:25:35.012]  at org.apache.solr.servlet.SolrServlet.init(SolrServlet.java:72)
[00:25:35.012]  at javax.servlet.GenericServlet.init(GenericServlet.java:69)
[00:25:35.012]  at
com.caucho.server.dispatch.ServletConfigImpl.createServletImpl(ServletConfigImpl.java:646)
[00:25:35.012]  at
com.caucho.server.dispatch.ServletConfigImpl.createServlet(ServletConfigImpl.java:587)
[00:25:35.012]  at
com.caucho.server.dispatch.ServletManager.init(ServletManager.java:154)
[00:25:35.012]  at
com.caucho.server.webapp.Application.start(Application.java:1654)
[00:25:35.012]  at
com.caucho.server.deploy.DeployController.startImpl(DeployController.java:621)
[00:25:35.012]  at
com.caucho.server.deploy.StartAutoRedeployAutoStrategy.startOnInit(StartAutoRedeployAutoStrategy.java:72)
[00:25:35.012]  at
com.caucho.server.deploy.DeployController.startOnInit(DeployController.java:509)
[00:25:35.012]  at
com.caucho.server.deploy.DeployContainer.start(DeployContainer.java:153)
[00:25:35.012]  at
com.caucho.server.webapp.ApplicationContainer.start(ApplicationContainer.java:670)
[00:25:35.012]  at com.caucho.server.host.Host.start(Host.java:420)
[00:25:35.012]  at
com.caucho.server.deploy.DeployController.startImpl(DeployController.java:621)
[00:25:35.012]  at
com.caucho.server.deploy.StartAutoRedeployAutoStrategy.startOnInit(StartAutoRedeployAutoStrategy.java:72)
[00:25:35.012]  at
com.caucho.server.deploy.DeployController.startOnInit(DeployController.java:509)
[00:25:35.012]  at
com.caucho.server.deploy.DeployContainer.start(DeployContainer.java:153)
[00:25:35.012]  at
com.caucho.server.host.HostContainer.start(HostContainer.java:504)
[00:25:35.012]  at
com.caucho.server.resin.ServletServer.start(ServletServer.java:971)
[00:25:35.012]  at
com.caucho.server.deploy.DeployController.startImpl(DeployController.java:621)
[00:25:35.012]  at
com.caucho.server.deploy.AbstractDeployControllerStrategy.start(AbstractDeployControllerStrategy.java:56)
[00:25:35.012]  at
com.caucho.server.deploy.DeployController.start(DeployController.java:517)
[00:25:35.012]  at
com.caucho.server.resin.ResinServer.start(ResinServer.java:546)
[00:25:35.012]  at com.caucho.server.resin.Resin.init(Resin.java)
[00:25:35.012]  at com.caucho.server.resin.Resin.main(Resin.java:625)
[00:25:35.012] Caused by: java.lang.NumberFormatException: empty String
[00:25:35.012]  at
sun.misc.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:994)
[00:25:35.012]  at java.lang.Float.parseFloat(Float.java:394)
[00:25:35.012]  at org.apache.solr.core.Config.getFloat(Config.java:174)
[00:25:35.012]  at
org.apache.solr.schema.IndexSchema.readConfig(IndexSchema.java:273)
[00:25:35.012]  ... 27 more
[00:25:35.021] javax.servlet.ServletException:
org.apache.solr.core.SolrException: Schema Parsing Failed
[00:25:35.021]  at
com.caucho.server.dispatch.ServletConfigImpl.createServlet(ServletConfigImpl.java:618)
[00:25:35.021]  at
com.caucho.server.dispatch.ServletManager.init(ServletManager.java:154)
[00:25:35.021]  at
com.caucho.server.webapp.Application.start(Application.java:1654)
[00:25:35.021]  at
com.caucho.server.deploy.DeployController.startImpl(DeployController.java:621)
[00:25:35.021]  at
com.caucho.server.deploy.StartAutoRedeployAutoStrategy.startOnInit(StartAutoRedeployAutoStrategy.java:72)
[00:25:35.021]  at
com.caucho.server.deploy.DeployController.startOnInit(DeployController.java:509)
[00:25:35.021]  at
com.caucho.server.deploy.DeployContainer.start(DeployContainer.java:153)
[00:25:35.021]  at
com.caucho.server.webapp.ApplicationContainer.start(ApplicationContainer.java:670)
[00:25:35.021]  at com.caucho.server.host.Host.start(Host.java:420)
[00:25:35.021]  at
com.caucho.server.deploy.DeployC

: I have the trunk version with patch #1 on SOLR-78 (the one edited at
: 11:59am).  When i run the war file on a windows machine running
: resin-3.0.21 it works fine.  When i run it on a linux box (debian)
: also running resin-3.0.21, i get:

ah .. okay, so you never tried the older version (i thought you ment you
had personally applied one of hte patches to your local copy)

: [00:25:35.025] Caused by: java.lang.NumberFormatException: empty String
: [00:25:35.025]  at
: sun.misc.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:994)
: [00:25:35.025]  at java.lang.Float.parseFloat(Float.java:394)
: [00:25:35.025]  at org.apache.solr.core.Config.getFloat(Config.java:174)
: [00:25:35.025]  at
: org.apache.solr.schema.IndexSchema.readConfig(IndexSchema.java:273)

Ah .. interesting ... that's parsing the version number from the schema,
and by the looks of it it's not getting the default version but an empty
string instead.

can you verify two things for me...

1) i'm assuming the <schema> tag in your schema.xml either doesn't have a
version="" attribute in it, or has an empty string (or pure white space)
as the value, is that correct?

2) can you try running resin with the java logging level at "fine" and
looking for a log line that includes the string "/schema/@version" and let
us know what it says?
Config.getFloat(path,def) only uses the default value if
getVal(path,false) returns null -- but i'm guessing DOMUtil.getText(Node)
is returning the empty string.

so is this a bug in the DOMUtil.getText(NOde) method i wrote, or should we
change Config.getVal, or should we change all of the Config.get*(path,def)
methods to use the default if getVal returns am empty string?

On 12/22/06, Chris Hostetter <[EMAIL PROTECTED]> wrote:
> 1) i'm assuming the <schema> tag in your schema.xml either doesn't have a
> version="" attribute in it, or has an empty string (or pure white space)
> as the value, is that correct?

This happens with the solr example.
I just verified it... downloaded resin-2.2.zip on windows, copied over
example/webapps/solr.war and example/solr/example and I got the
same exception on startup.

> so is this a bug in the DOMUtil.getText(NOde) method i wrote, or should we
> change Config.getVal, or should we change all of the Config.get*(path,def)
> methods to use the default if getVal returns am empty string?

I'd rather not unless we really have to.  Seems like we should be able
to tell the difference of foo="" and the absense of foo.
-Yonik

Ryan, while the issue with Resin's parser is sorted out, you can use
the built-in XML parser  in Sun's JVM.  There is a comment in the
web.xml that shows how (so you need to explode the WAR and edit the
web.xml).

  <!-- Uncomment if you are trying to use a Resin version before 3.0.19.
    Their XML implementation isn't entirely compatible with Xerces.
    Below are the implementations to use with Sun's JVM.
  <system-property javax.xml.xpath.XPathFactory             "com.sun.org.apache.xpath.internal.jaxp.XPathFactoryImpl"/>
  <system-property javax.xml.parsers.DocumentBuilderFactory             "com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl"/>
  <system-property javax.xml.parsers.SAXParserFactory             "com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl"/>
   -->
-Yonik

yes, this works.  But i am running resin 3.0.21 (after 19!)

Chris, i'll send you "fine" log trace, in a moment
On 12/22/06, Yonik Seeley <[EMAIL PROTECTED]> wrote:
> Ryan, while the issue with Resin's parser is sorted out, you can use
> the built-in XML parser  in Sun's JVM.  There is a comment in the
> web.xml that shows how (so you need to explode the WAR and edit the
> web.xml).
>
>   <!-- Uncomment if you are trying to use a Resin version before 3.0.19.
>     Their XML implementation isn't entirely compatible with Xerces.
>     Below are the implementations to use with Sun's JVM.
>   <system-property javax.xml.xpath.XPathFactory>              "com.sun.org.apache.xpath.internal.jaxp.XPathFactoryImpl"/>
>   <system-property javax.xml.parsers.DocumentBuilderFactory>              "com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl"/>
>   <system-property javax.xml.parsers.SAXParserFactory>              "com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl"/>
>    -->
>
>
> -Yonik
>

On 12/22/06, ryan mckinley <[EMAIL PROTECTED]> wrote:
> yes, this works.  But i am running resin 3.0.21 (after 19!)

Yeah... they had an earlier bug that was fixed in 3.0.20, but I guess
that when we tried to fix the parsing for those older versions, it
broke against their newer versions.

-Yonik

>
> 1) i'm assuming the <schema> tag in your schema.xml either doesn't have a
> version="" attribute in it, or has an empty string (or pure white space)
> as the value, is that correct?
>

i have version="1.1" just as in the example schema.
> 2) can you try running resin with the java logging level at "fine" and
> looking for a log line that includes the string "/schema/@version" and let
> us know what it says?
>

I've been messing with the logging, and the area of interist does not
have anything in it.  I *think* i found a real solution though.

In the patched DOMUtil.getText(Node nd, StringBuffer buf), there is a
case statement with:

    case Node.ATTRIBUTE_NODE: /* fall through */
    case Node.ELEMENT_NODE: /* fall through */
    case Node.ENTITY_NODE: /* fall through */
    case Node.ENTITY_REFERENCE_NODE: /* fall through */
    case Node.DOCUMENT_FRAGMENT_NODE:
      NodeList childs = nd.getChildNodes();
      for (int i = 0; i < childs.getLength(); i++) {
        Node child = childs.item(i);
        short childType = child.getNodeType();
        if (childType != Node.COMMENT_NODE &&
            childType != Node.PROCESSING_INSTRUCTION_NODE) {
          getText(child, buf);
        }
      }
      break;

    case Node.TEXT_NODE: /* fall through */
    case Node.CDATA_SECTION_NODE: /* fall through */
    case Node.COMMENT_NODE: /* fall through */
    case Node.PROCESSING_INSTRUCTION_NODE: /* fall through */
      buf.append(nd.getNodeValue());
      break;

The problem occured with a Node.ATTRIBUTE_NODE.  It would get the text
from the body (returning "" in this case).  I moved the
Node.ATTRIBUTE_NODE case so it is treated the same as TEXT_NODE and it
works for resin and the tests pass.

Is this a real solution? or does it just work for the resin XML parser?

ryan

here is a patch if that makes my change any clearer.  Should i post it to:
http://issues.apache.org/jira/browse/SOLR-78
?

On 12/22/06, ryan mckinley <[EMAIL PROTECTED]> wrote:
> >
> > 1) i'm assuming the <schema> tag in your schema.xml either doesn't have a
> > version="" attribute in it, or has an empty string (or pure white space)
> > as the value, is that correct?
> >
>
> i have version="1.1" just as in the example schema.
>
>
> > 2) can you try running resin with the java logging level at "fine" and
> > looking for a log line that includes the string "/schema/@version" and let
> > us know what it says?
> >
>
> I've been messing with the logging, and the area of interist does not
> have anything in it.  I *think* i found a real solution though.
>
> In the patched DOMUtil.getText(Node nd, StringBuffer buf), there is a
> case statement with:
>
>     case Node.ATTRIBUTE_NODE: /* fall through */
>     case Node.ELEMENT_NODE: /* fall through */
>     case Node.ENTITY_NODE: /* fall through */
>     case Node.ENTITY_REFERENCE_NODE: /* fall through */
>     case Node.DOCUMENT_FRAGMENT_NODE:
>       NodeList childs = nd.getChildNodes();
>       for (int i = 0; i < childs.getLength(); i++) {
>         Node child = childs.item(i);
>         short childType = child.getNodeType();
>         if (childType != Node.COMMENT_NODE &&
>             childType != Node.PROCESSING_INSTRUCTION_NODE) {
>           getText(child, buf);
>         }
>       }
>       break;
>
>     case Node.TEXT_NODE: /* fall through */
>     case Node.CDATA_SECTION_NODE: /* fall through */
>     case Node.COMMENT_NODE: /* fall through */
>     case Node.PROCESSING_INSTRUCTION_NODE: /* fall through */
>       buf.append(nd.getNodeValue());
>       break;
>
> The problem occured with a Node.ATTRIBUTE_NODE.  It would get the text
> from the body (returning "" in this case).  I moved the
> Node.ATTRIBUTE_NODE case so it is treated the same as TEXT_NODE and it
> works for resin and the tests pass.
>
> Is this a real solution? or does it just work for the resin XML parser?
>
> ryan
>

On 12/22/06, ryan mckinley <[EMAIL PROTECTED]> wrote:
> here is a patch if that makes my change any clearer.  Should i post it to:
> http://issues.apache.org/jira/browse/SOLR-78
> ?

That issue has been closed (and is in our upcoming 1.1 release that
has already been cut),
so you could open a new issue and attach a patch).

-Yonik

: The problem occured with a Node.ATTRIBUTE_NODE.  It would get the text
: from the body (returning "" in this case).  I moved the
: Node.ATTRIBUTE_NODE case so it is treated the same as TEXT_NODE and it
: works for resin and the tests pass.

Hmmm... yeah, this seems to be a mistake in the DOM-Level-3-Core
description of what getText is suppose to do ... it says that for
ATTRIBUTE_NODE you should concat all of the children -- but how would an
ATTRIBUTE ever have children?

I'll try to test this out soon.

-Hoss

: : Node.ATTRIBUTE_NODE case so it is treated the same as TEXT_NODE and it
: : works for resin and the tests pass.
:
: Hmmm... yeah, this seems to be a mistake in the DOM-Level-3-Core
: description of what getText is suppose to do ... it says that for
: ATTRIBUTE_NODE you should concat all of the children -- but how would an
: ATTRIBUTE ever have children?

Did some more reading ... according to DOM-Level-3-Core, an Attr's allowed
children are "Text" and "EntityReference".

Xerces2-j NodeImpl..getTextContent duplicates the table from the
Level-3-Core docs (which is also in the java 1.5 javadocs for
org.w3c.dom.Node.getTextContent()) which the notable exception that they
move ATTRIBUTE_NODE down into the second row (indicating nodeValue should
be used instead of concating the children) ... the impl backs this up
(AttrImpl inherits getTextContent from NodeImpl, which by default returns
this.getNodeValue())

http://xerces.apache.org/xerces2-j/javadocs/xerces2/org/apache/xerces/dom/NodeImpl.html#getTextContent()
http://java.sun.com/j2se/1.5.0/docs/api/org/w3c/dom/Node.html#getTextContent()
http://svn.apache.org/viewvc/xerces/java/trunk/src/org/apache/xerces/dom/AttrImpl.java?view=markup
http://svn.apache.org/viewvc/xerces/java/trunk/src/org/apache/xerces/dom/NodeImpl.java?view=markup

Fortunately, the DOM Spec says that accessing the Attr.nodeValue is
defined to be Attr.value, which is documented as...

On retrieval, the value of the attribute is returned as a string.
Character and general entity references are replaced with their values.

...so even if someone out there is acctually obeying the spec about
giving Attr's child nodes, we should still be safe using getNodeValue in
the Node.ATTRIBUTE_NODE case since the spec says that needs to work too.

-Hoss