[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: DOM: Document.createElement() - AbstractMethodError

On Mon, 17 Jul 2000, Lars Martin wrote:
> Hi,
> 
> On Mon, 17 Jul 2000, Manfred Seitter wrote:
> > Hi folks,
> > 
> > I simply try to modify a XML document thats already stored in the OzoneDB. I
> > call the "Document.createElement()" method and on the server-side an
> > "AbstractMethodException" is thrown.
> > 
> > Here's the code snippet.
> > ---------------------------------------------------------------
> > 
> >     infoTreeDoc = (Document)
> > database.objectForName( INFOTREE_NAME );
> >              }
> > 
> >    int id = 0;
> >    Node curNode;
> > 
> >    if( infoTreeDoc instanceof Document )
> >    {
> > //    curNode = infoTreeDoc.createAttribute( "an
> > attribute" );
> > //    curNode = infoTreeDoc.createTextNode( "just a
> > textnode" );
> > //    curNode = infoTreeDoc.createComment( "just a
> > comment" );
> >     curNode = infoTreeDoc.createElement(
> > "rootElement" );
> > //    curNode =
> > infoTreeDoc.createProcessingInstruction( "target", "data" );
> > //    curNode = infoTreeDoc.createEntityReference(
> > "data" );
> > //    curNode = infoTreeDoc.createCDATASection(
> > "data" );
> > 
> > //    ( (Element)curNode ).setAttribute( "id", new
> > Integer( id ).toString() );
> > //    infoTreeDoc.appendChild( curNode );
> > 
> >     /* build a demo tree */
> >     int maxLength = 5;
> >     int maxDepth = 3;
> > //    buildTree( curElement, 0, maxDepth, maxLength
> > );
> >    }
> > ---------------------------------------------------------------
> > and thats the exception raised on the serverside
> > ---------------------------------------------------------------
> > [info] (396) InvokeServer: connection established...
> > [info] (001) InvokeServer: user logged in: root
> > [warn] (001) Transaction: ta(-93): uncaught exception: (java.lang.AbstractMet
> > Error)
> >     java.lang.AbstractMethodError
> >         at java.lang.reflect.Method.invoke(Native Method)
> >         at org.ozoneDB.core.AbstractObjectContainer.invokeTarget(AbstractObje
> >             ctContainer.java:204)
> >         at org.ozoneDB.core.Transaction.invokeObject(Transaction.java:463)
> >         at org.ozoneDB.core.DbRemote.DbInvoke.perform(DbInvoke.java:61)
> >         at org.ozoneDB.core.Transaction.performCommand(Transaction.java:217)
> >         at org.ozoneDB.core.TransactionManager.performCommand(TransactionMana
> >             ger.java:316)
> >         at org.ozoneDB.core.TransactionManager.completeTransaction(Transactio
> >             nManager.java:285)
> >         at org.ozoneDB.core.TransactionManager.handleCommand(TransactionManag
> >             er.java:203)
> >         at org.ozoneDB.core.InvokeServer.handleClientEvent(InvokeServer.java:
> >             77)
> >         at org.ozoneDB.DxLib.net.DxMultiServerClient.run(DxMultiServerClient.
> >             java:37)
> >         at java.lang.Thread.run(Unknown Source)
> > ---------------------------------------------------------------
> > 
> > Perhaps someone of you got an idea? (I've already checked my classpath to
> > ensure the use of xerces that is delivered with ozone)
> > 
> > Environment: OZONE 5.1 / Win32 / SUN JDK1.3
> > 
> > Thanks in advance ... Fred
> 
> I see no XML problem with your code so I assume that this is caused by the JDK
> 1.3 and/or an internal ozone database error. Falko?

Fred, this sounds like a problem that was reported by another user: jdk1.3 on
win seems to return the array of methods of a class in different order for
subsequent calls of getMethods(). Since the proxies rely on the array order to
identify the method that should be invoked on the server side this is a
problem.  This was fixed (at least I thought so) in ozone 0.5. 

Okay, I guess you are working with ozone the first time, so there are no old
proxies, right? If so, please start the server with '-debug3'. This will force
it to output the method index of each method that is invoked by an client
proxy. (besides many other things ;)

The last lines of the form:

[debug](124) TransactionManager: newTransaction()***************************** 
[debug](124) TransactionManager:performCommand(): ta(9), [DbInvoke: 2] 
...
[debug](124) WizardObjectContainer: invoke(): method=convertDOM

are indicating the command and the method index that was executed when the
exception was thrown (in the above example: command=DbInvoke, mindex=2). In
debug3 mode the server also outputs the name of the method it is executing.
Now, the question is: are server method and client method the same in your
test, Fred?


Falko
-- 
______________________________________________________________________
Falko Braeutigam                         mailto:falko@softwarebuero.de
SMB GmbH                                   http://www.softwarebuero.de