You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Ross Mason <me...@rossmason.com> on 2003/06/27 18:10:30 UTC
RE: [Betwixt] Derived Class support
Hi Robert,
Sorry for the delay, but things have been very hectic.
I've attached the source code and a CVS diff of the changes I've made for
the derived bean support.
I'm going away for a few months next week so if you need anything else
please let me know asap.
There is a minor bug with this patch that occasionally throws an
IllegalArgumentException when trying to set attributes on a bean. Even
though we get this exception the bean's attributes do get set. I think is
caused when new rules are registered for a derived bean and the digester
becomes briefly out of sync until the top object is popped and a new derived
object is created and put on the stack. I have not had time to look into
this, and as it doesn't cause any problems we have ignored it in our project
for the time being. I've enclosed a trace for you.
Ross
WARN [main] (MethodUpdater.java:156) - Cannot evaluate method: setName on
bean: com.estafet.smse.persistence.Occupation@1ee2c2c of type:
com.estafet.smse.persistence.Occupation with value: Nurse of type:
java.lang.String
INFO [main] (MethodUpdater.java:197) - Caught exception:
java.lang.IllegalArgumentException: object is not an instance of declaring
class
java.lang.IllegalArgumentException: object is not an instance of declaring
class
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
org.apache.commons.betwixt.expression.MethodUpdater.update(MethodUpdater.jav
a:152)
at
org.apache.commons.betwixt.io.BeanRuleSet$ReadContext$PrimitiveRule.body(Bea
nRuleSet.java:576)
at
org.apache.commons.digester.Digester.endElement(Digester.java:800)
at
org.apache.xerces.parsers.AbstractSAXParser.endElement(AbstractSAXParser.jav
a:579)
at
org.apache.xerces.impl.XMLNamespaceBinder.endElement(XMLNamespaceBinder.java
:646)
at
org.apache.xerces.impl.dtd.XMLDTDValidator.handleEndElement(XMLDTDValidator.
java:1972)
at
org.apache.xerces.impl.dtd.XMLDTDValidator.endElement(XMLDTDValidator.java:8
78)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.handleEndElement(XMLDo
cumentFragmentScannerImpl.java:1144)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocu
mentFragmentScannerImpl.java:987)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatc
her.dispatch(XMLDocumentFragmentScannerImpl.java:1445)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocume
ntFragmentScannerImpl.java:333)
at
org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:524)
at
org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:580)
at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:152)
at
org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:116
9)
at org.apache.commons.digester.Digester.parse(Digester.java:1322)
at
com.estafet.smse.message.JournalMessage.create(JournalMessage.java:92)
at
com.estafet.smse.message.JournalMessage.<init>(JournalMessage.java:46)
at
com.estafet.smse.test.message.MessagesTest.testJournalMessage(MessagesTest.j
ava:210)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at junit.framework.TestCase.runTest(TestCase.java:166)
at junit.framework.TestCase.runBare(TestCase.java:140)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:131)
at junit.framework.TestSuite.runTest(TestSuite.java:173)
at junit.framework.TestSuite.run(TestSuite.java:168)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRu
nner.java:392)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.
java:276)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner
.java:167)
-----Original Message-----
From: robert burrell donkin [mailto:robertburrelldonkin@blueyonder.co.uk]
Sent: 09 May 2003 16:05
To: Jakarta Commons Developers List
Subject: Re: [Betwixt] Derived Class support
hi ross
that all sounds great!
the best way is to do a cvs diff -u against CVS HEAD and either post it to
the list or add it to bugzilla.
- robert
On Friday, May 2, 2003, at 03:26 PM, Ross Mason wrote:
> Hi James/ Robert,
>
>
>
> Just to give you an update. I've got betwixt working with most of the
> functionality needed for Derived class support -
>
>
>
> - Population of derived class attributes from the BeanReader now
> works.
>
> - It also supports population of beans with common attributes. i.
> e.
> 'Person' has an attribute 'name' only, 'Consultant' and 'Hitman' extend
> Person. They both have a attributes hourlyRate, but the attribute is not
> derived. I needed this scenario supported in my code. Currently, only
> primitive common attribute types are supported.
>
> - To demonstrate this I've written a new test case in the derived
> package. This tests all the old and new functionality and also tests
> round-tripping.
>
> - I haven't had time to write support in the .betwixt files to
> specify whether the className attribute should be written for a bean or
> made
> the attribute name 'className' configurable (as James suggested) . I've
> been
> testing the code with a derived XMLIntrospector that checks to see if the
> bean being introspected is of a certain base-class type and includes a
> className attribute descriptor. Maybe we should let users register derived
> classes with the XMLIntrospector and determine whether the attribute
> should
> be written automatically?
>
> - I've been running my project with this code for the past week
> without any problems and all the existing test-cases work.
>
>
>
> The code I've written does the job but there may be better ways of doing
> it
> (especially the support for common attributes). Betwixt as it stands is
> pretty hard to extend and it's apparent that certain areas need
> re-factoring/ re-architecting. I would be keen to get involved with this,
> but I'm pretty busy with other stuff for the next 6 weeks.
>
>
>
> Anyway, what now? How do you want me to get the code to you so you can
> check
> it over?
>
>
>
>
>
> Ross
>
> -------------------------------------------
>
> Mobile: +44 (0) 7745 944 082
>
> Work: +44 (0) 20 7503 4811
>
> Fax: +44 (0) 20 7503 4811
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [Betwixt] Derived Class support
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
hi ross
thanks for the patch. i've taken a quick look at it and it seems fine.
i'll go through it in detail a little later. (i've got a multiple versions
checked out at the moment with various patches and enhancements applied so
it's a little difficult for me just now.)
please you could (in future) post your diffs in -u format (see
http://jakarta.apache.org/commons/patches.html).
- robert
On Friday, June 27, 2003, at 05:10 PM, Ross Mason wrote:
> Hi Robert,
>
> Sorry for the delay, but things have been very hectic.
>
> I've attached the source code and a CVS diff of the changes I've made for
> the derived bean support.
>
> I'm going away for a few months next week so if you need anything else
> please let me know asap.
>
> There is a minor bug with this patch that occasionally throws an
> IllegalArgumentException when trying to set attributes on a bean. Even
> though we get this exception the bean's attributes do get set. I think is
> caused when new rules are registered for a derived bean and the digester
> becomes briefly out of sync until the top object is popped and a new
> derived
> object is created and put on the stack. I have not had time to look into
> this, and as it doesn't cause any problems we have ignored it in our
> project
> for the time being. I've enclosed a trace for you.
>
> Ross
>
> WARN [main] (MethodUpdater.java:156) - Cannot evaluate method: setName on
> bean: com.estafet.smse.persistence.Occupation@1ee2c2c of type:
> com.estafet.smse.persistence.Occupation with value: Nurse of type:
> java.lang.String
> INFO [main] (MethodUpdater.java:197) - Caught exception:
> java.lang.IllegalArgumentException: object is not an instance of declaring
> class
> java.lang.IllegalArgumentException: object is not an instance of declaring
> class
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
> 39
> )
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl
> .java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at
> org.apache.commons.betwixt.expression.MethodUpdater.update(MethodUpdater.
> jav
> a:152)
> at
> org.apache.commons.betwixt.io.BeanRuleSet$ReadContext$PrimitiveRule.body(
> Bea
> nRuleSet.java:576)
> at
> org.apache.commons.digester.Digester.endElement(Digester.java:800)
> at
> org.apache.xerces.parsers.AbstractSAXParser.endElement(AbstractSAXParser.
> jav
> a:579)
> at
> org.apache.xerces.impl.XMLNamespaceBinder.endElement(XMLNamespaceBinder.java
> :646)
> at
> org.apache.xerces.impl.dtd.XMLDTDValidator.handleEndElement
> (XMLDTDValidator.
> java:1972)
> at
> org.apache.xerces.impl.dtd.XMLDTDValidator.endElement(XMLDTDValidator.java:
> 8
> 78)
> at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.handleEndElement
> (XMLDo
> cumentFragmentScannerImpl.java:1144)
> at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement
> (XMLDocu
> mentFragmentScannerImpl.java:987)
> at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatc
> her.dispatch(XMLDocumentFragmentScannerImpl.java:1445)
> at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument
> (XMLDocume
> ntFragmentScannerImpl.java:333)
> at
> org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:524)
> at
> org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:580)
> at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:152)
> at
> org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:
> 116
> 9)
> at org.apache.commons.digester.Digester.parse(Digester.java:1322)
> at
> com.estafet.smse.message.JournalMessage.create(JournalMessage.java:92)
> at
> com.estafet.smse.message.JournalMessage.<init>(JournalMessage.java:46)
> at
> com.estafet.smse.test.message.MessagesTest.testJournalMessage
> (MessagesTest.j
> ava:210)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
> 39
> )
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl
> .java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at junit.framework.TestCase.runTest(TestCase.java:166)
> at junit.framework.TestCase.runBare(TestCase.java:140)
> at junit.framework.TestResult$1.protect(TestResult.java:106)
> at junit.framework.TestResult.runProtected(TestResult.java:124)
> at junit.framework.TestResult.run(TestResult.java:109)
> at junit.framework.TestCase.run(TestCase.java:131)
> at junit.framework.TestSuite.runTest(TestSuite.java:173)
> at junit.framework.TestSuite.run(TestSuite.java:168)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests
> (RemoteTestRu
> nner.java:392)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run
> (RemoteTestRunner.
> java:276)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main
> (RemoteTestRunner
> .java:167)
>
> -----Original Message-----
> From: robert burrell donkin [mailto:robertburrelldonkin@blueyonder.co.uk]
> Sent: 09 May 2003 16:05
> To: Jakarta Commons Developers List
> Subject: Re: [Betwixt] Derived Class support
>
> hi ross
>
> that all sounds great!
>
> the best way is to do a cvs diff -u against CVS HEAD and either post it to
> the list or add it to bugzilla.
>
> - robert
>
> On Friday, May 2, 2003, at 03:26 PM, Ross Mason wrote:
>
>> Hi James/ Robert,
>>
>>
>>
>> Just to give you an update. I've got betwixt working with most of the
>> functionality needed for Derived class support -
>>
>>
>>
>> - Population of derived class attributes from the BeanReader now
>> works.
>>
>> - It also supports population of beans with common attributes.
>> i.
>> e.
>> 'Person' has an attribute 'name' only, 'Consultant' and 'Hitman' extend
>> Person. They both have a attributes hourlyRate, but the attribute is not
>> derived. I needed this scenario supported in my code. Currently, only
>> primitive common attribute types are supported.
>>
>> - To demonstrate this I've written a new test case in the
>> derived
>> package. This tests all the old and new functionality and also tests
>> round-tripping.
>>
>> - I haven't had time to write support in the .betwixt files to
>> specify whether the className attribute should be written for a bean or
>> made
>> the attribute name 'className' configurable (as James suggested) . I've
>> been
>> testing the code with a derived XMLIntrospector that checks to see if the
>> bean being introspected is of a certain base-class type and includes a
>> className attribute descriptor. Maybe we should let users register
>> derived
>> classes with the XMLIntrospector and determine whether the attribute
>> should
>> be written automatically?
>>
>> - I've been running my project with this code for the past week
>> without any problems and all the existing test-cases work.
>>
>>
>>
>> The code I've written does the job but there may be better ways of doing
>> it
>> (especially the support for common attributes). Betwixt as it stands is
>> pretty hard to extend and it's apparent that certain areas need
>> re-factoring/ re-architecting. I would be keen to get involved with
>> this,
>> but I'm pretty busy with other stuff for the next 6 weeks.
>>
>>
>>
>> Anyway, what now? How do you want me to get the code to you so you can
>> check
>> it over?
>>
>>
>>
>>
>>
>> Ross
>>
>> -------------------------------------------
>>
>> Mobile: +44 (0) 7745 944 082
>>
>> Work: +44 (0) 20 7503 4811
>>
>> Fax: +44 (0) 20 7503 4811
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org