... until the collector arrives ...

This "blog" is really just a scratchpad of mine. There is not much of general interest here. Most of the content is scribbled down "live" as I discover things I want to remember. I rarely go back to correct mistakes in older entries. You have been warned :)

2006-02-28

Apache Axis

I was getting a strange error message from Axis 1.3 stating that there was no deserializer for the type xs:string (or, alternatively, that there was no serializer for java.lang.String).  It turned out that the problem was that I had previously deployed a web service that had custom serializers but had then changed the JAR so that it no longer contained the classes that supported them.  In addition, I had not undeployed the web service that reference those serializers.  Apparently, if Axis is unable to load any custom serializer, it fails to load all serializers -- including the built-in ones.  The moral of the story is that if you see strange serialization errors, go check Axis' server-config.wsdd for dead entries.

2006-02-24

LDAP Specifications

LDAP is defined in RFC 1777.  LDAP search filter syntax is documented in RFC 1960.

BEA ALDSP

Today Wing found a problem when trying to write back document changes using BEA ALDSP.  The error message stated that the heritage of the changes was ambiguous.  Viewing the query plan for the relevant data source, we found a warning stating that the type of the result did not match the type of the document.  Further investigation revealed that if we changed the return type of the data source function from 'Activity' to 'Activity*', then everything worked -- except that now the document was wrapped in one of BEA's famous generated 'array' types.  It turns out that the expression that was computing the return result implied a maxOccurs of "unbounded", e.g.  for $activity in ns0:getActivity().  We knew, however, that this function always returned no more than one result.  Thus, the problem was solved by changing the expression to let $activity := ns0:getActivity()[1].  Interesting that the compiler was correctly identifying that the expression actually returned Activity* but didn't complain when the function was declared as returning Activity.

2006-02-23

XMLBeans vs HTTP Requests

I saw a strange problem where one of the XMLBeans parse functions failed intermittently when parsing the input stream of an HTTP request.  The exception is:

Caused by: org.xml.sax.SAXParseException: Unexpected end of file after null
	at com.bluecast.xml.Piccolo.reportFatalError(Piccolo.java:1003)
	at com.bluecast.xml.Piccolo.reportFatalError(Piccolo.java:990)
	at com.bluecast.xml.Piccolo.yyerror(Piccolo.java:1302)
	at com.bluecast.xml.Piccolo.yyparse(Piccolo.java:1403)
	at com.bluecast.xml.Piccolo.parse(Piccolo.java:702)
	at com.bea.xbean.store.Root$SaxLoader.load(Root.java:735)
	... 29 more

A quick web search revealed that others had hit this too:

Apache JIRA issue XMLBEANS-226: Exception "Unexpected end of file after null"

The JIRA issue notes that the problem is in the Piccolo parser.  Apparently, that parser does not close the input stream once parsing is complete.  However, it does close the stream the next time you do a parse (which may not happen for an indefinite period of time).  In the absence of a fix from the Piccolo team, the workaround is to close the input stream yourself.  Unfortunately, that causes problems in a subsequent parse because it will attempt to close the stream again (throwing another exception).  Thus, you must wrap the stream with a class that overrides the close method to be tolerant of multiple closes.  That workaround works.

2006-02-22

Eclipse Plug-in Development

I've hit this issue before, but it took much effort to rediscover the answer, so I'm writing it down this time...

When you create a plug-in that simply packages and re-exports pre-existing JAR files, make sure that the following things are true:

  1. the JARs are all listed in the project build path ("Libraries" tab)
  2. the JARs have all been exported in the project build path ("Order and Export" tab)
  3. the JARs are all listed in the 'Classpath' list in the manifest ("Runtime" tab)
  4. the JAR packages that you wish to export (normally all of them) are listed in the export listof the manifest ("Runtime" tab)
  5. the JARs are all selected in the binary build list of the manifest ("Build" tab)

I had done all of these steps but #2.  A dependent plug-in complained that package names could not be resolved -- even though all other signs indicated that the packages were accessible.

2006-02-21

BEA XQuery

BEA's implementation of XQuery does not support recursion.  If you try it, you get an exception like:

weblogic.xml.query.exceptions.XQuerySystemException: {bea-err}SYS006: Function {lib:DsTest/WorkItemHierarchy/hierarchy}factorial is recursive; this is not supported (sorry)
	at weblogic.xml.query.operators.UserDefinedFunction.codeGenRecursiveFunction(UserDefinedFunction.java:174)
	at weblogic.xml.query.runtime.core.RecFuncIterator.fetchNext(RecFuncIterator.java:69)
	at weblogic.xml.query.iterators.GenericIterator.next(GenericIterator.java:109)

BEA SDO

BEA's SDO implementation does not appear to stand alone.  Under certain circumstances where an SDO graph is modified, the change log contains XPath expressions of sufficient complexity that the BEA SDO stack elects to invoke their full XQuery implementation.  In particular, a data graph was modified and converted to XML.  Its change summary looked like this:

<changeSummary>
  <Activity com:ref="/Activities/Activity[10]">
    <Required>1</Required>
  </Activity>
  <Activity com:ref="/Activities/Activity[11]">
    <Required>1</Required>
  </Activity>
...

When trying to rematerialize the graph using DataGraphImpl.parse(), an exception was thrown:

java.lang.UnsupportedOperationException: This query is too complex to be processed.
	at com.bea.xbean.store.XqrlDelegate.invoke(XqrlDelegate.java:70)
	at com.bea.xbean.store.XqrlDelegate.compilePath(XqrlDelegate.java:39)
	at com.bea.xbean.store.Path$XqrlPathImpl.create(Path.java:265)
	at com.bea.xbean.store.Path.getCompiledPath(Path.java:169)
	at com.bea.xbean.store.Path.getPath(Path.java:81)
	at com.bea.xbean.store.Path.getPath(Path.java:58)
	at com.bea.xbean.store.Path.select(Path.java:43)
	at com.bea.xbean.store.Cursor.selectPath(Cursor.java:2898)
	at com.bea.xbean.values.XmlObjectBase.selectPath(XmlObjectBase.java:395)
	at com.bea.xbean.values.XmlObjectBase.selectPath(XmlObjectBase.java:379)
	at com.bea.sdo.impl.DataObjectHandler.selectSdoPath(DataObjectHandler.java:1323)
	at com.bea.sdo.impl.DataObjectHandler.get(DataObjectHandler.java:212)
	at com.mm.platform.xbean.impl.ActivitiesDocumentImpl.get(Unknown Source)
	at com.bea.sdo.impl.DataGraphImpl.parseChildren(DataGraphImpl.java:520)
	at com.bea.sdo.impl.DataGraphImpl.parseDataGraphDocument(DataGraphImpl.java:451)
	at com.bea.sdo.impl.DataGraphImpl.(DataGraphImpl.java:88)
	at com.bea.sdo.impl.DataGraphImpl.(DataGraphImpl.java:96)

At first I tried simply adding BEA's xqrl.jar, which contains their XQuery engine.  However, the behaviour did not change.  Further experimentation revealed that the JARs wlxbean.jar was also necessary.  However, this combination only pushed the problem deeper:

java.lang.RuntimeException: weblogic/apache/xerces/impl/xs/SchemaSymbols
	at com.bea.xbean.store.XqrlDelegate.throwRuntimeException(XqrlDelegate.java:59)
	at com.bea.xbean.store.XqrlDelegate.invoke(XqrlDelegate.java:81)
	at com.bea.xbean.store.XqrlDelegate.compilePath(XqrlDelegate.java:39)
	at com.bea.xbean.store.Path$XqrlPathImpl.create(Path.java:265)
	at com.bea.xbean.store.Path.getCompiledPath(Path.java:169)
	at com.bea.xbean.store.Path.getPath(Path.java:81)
	at com.bea.xbean.store.Path.getPath(Path.java:58)
	at com.bea.xbean.store.Path.select(Path.java:43)
	at com.bea.xbean.store.Cursor.selectPath(Cursor.java:2898)
	at com.bea.xbean.values.XmlObjectBase.selectPath(XmlObjectBase.java:395)
	at com.bea.xbean.values.XmlObjectBase.selectPath(XmlObjectBase.java:379)
	at com.bea.sdo.impl.DataObjectHandler.selectSdoPath(DataObjectHandler.java:1323)
	at com.bea.sdo.impl.DataObjectHandler.get(DataObjectHandler.java:212)
	at com.mm.platform.xbean.impl.ActivitiesDocumentImpl.get(Unknown Source)
	at com.bea.sdo.impl.DataGraphImpl.parseChildren(DataGraphImpl.java:520)
	at com.bea.sdo.impl.DataGraphImpl.parseDataGraphDocument(DataGraphImpl.java:451)
	at com.bea.sdo.impl.DataGraphImpl.(DataGraphImpl.java:88)
	at com.bea.sdo.impl.DataGraphImpl.(DataGraphImpl.java:96)

You can see from the stack trace that BEA's own version of Xerces is required.  This, and the classes that support it, are available in weblogic.jar -- a 50 megabyte wonder.  It would appear that the whole WebLogic infrastructure needs to be pulled into the application just to rematerialize an SDO data graph object.  Thus, BEA's SDO does not appear to be "standalone".  Looking over the code for com.bea.xbean.store.Path, I can see that it attempts to use the built-in XBean XPath engine, falling back to Jaxen and XQRL if necessary.  My casual inspect was not enough to determine the circumstances under which each occurred.

2006-02-02

Embedded Tomcat

When using embedded Tomcat, the error message:

HTTP/1.1 400 No Host matches server name 127.0.0.1

can be caused by neglecting to start a context path with a slash.  That is, don't use this:

Context context = embedded.createContext("mycontext", webAppBase);

use this:

Context context = embedded.createContext("/mycontext", webAppBase);

 

Blog Archive