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/05/02 16:26:42 UTC
[Betwixt] Derived Class support
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
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
RE: [Betwixt] Derived Class support
Posted by Ross Mason <me...@rossmason.com>.
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
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