You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Igor Marakov <ig...@ivmsystems.com> on 2006/03/01 22:40:22 UTC
[betwixt] Reader registration problem
I wonder if anybody had seen this:
When reader registration map is created for incoming XML translation it is
created with tag/class pairs.
I ran today into the situations when IF an element of the registration
HashMap in the reader has NOT NULL "next" element, then during the
translation instance of the wrong class is created.
Unfortunately I cannot provide a real example but, here is what happens:
** registration process **
...
reader.registerBeanClass("mybean", com.rather.long.class.name.Mybean);
reader.registerBeanClass("mybeanSimilarName",
com.rather.long.class.name.MybeanSimilarName);
...
What I see in debugger:
** resulting HashMap ** inside the reader ( registeredClasses )
HashMap$Entry [xx] value com.rather.long.class.name.Mybean
Field "key" com.rather.long.class.name.Mybean
Field "next" HashMap$Entry com.rather.long.class.name.MybeanSimilarName
** On translation of the XML element "mybeanSimilarName"
** Bean factory ( I have my own chained in ) **
reports two beans being instantiated:
com.rather.long.class.name.Mybean
com.rather.long.class.name.MybeanSimilarName
** resulting object is **
com.rather.long.class.name.Mybean
Thanks,
Igor
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
RE: [betwixt] Exception suppression
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Tue, 2006-03-07 at 17:21 -0500, Igor Marakov wrote:
> Robert,
> Do you have an approximate list of exceptions that SHOULD be handled by
> betwixt?
i'm not sure a general list is possible: the semantics of each method
mean that it would need to be done on a case-by-case basis. for some
APIs, an exception may indicate that the object is basically DOA, others
may throw exceptions when the input is outside acceptable bounds. there
are also some APIs which throw exceptions to communicate unusual
circumstances which are not necessarily errors. in this last case, users
may not want the mapping to terminate.
if i'd have designed the interface, i would probably have defaulted to
rethrowing all target exceptions but i'd have been wrong. this is
probably something that should be configurable: factor out a strategy
for processing the exception. have a switch in the configuration and let
users choose.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
RE: [betwixt] Exception suppression
Posted by Igor Marakov <ig...@ivmsystems.com>.
Robert,
Do you have an approximate list of exceptions that SHOULD be handled by
betwixt?
Thanks,
Igor
-----Original Message-----
From: robert burrell donkin [mailto:robertburrelldonkin@blueyonder.co.uk]
Sent: Tuesday, March 07, 2006 5:06 PM
To: Jakarta Commons Users List
Subject: Re: [betwixt] Exception suppression
On Tue, 2006-03-07 at 11:13 -0500, Igor Marakov wrote:
> I recently ran into the situation where betwixt is suppressing exceptions
> during the translation.
> I don't think it is a good idea.
> Enclosing application code should be aware that data that it expecting
ain't
> coming. Here is the example of the unsuccessful translation of the SQLJ
> object that is coming from the DB and is supposed to be translated into
the
> normal java bean. Translation fails due to SQLException, but application
> code is not getting any indication of it.
>
> Question: Is there the way to switch this behavior off or limit it to
> certain kinds of exceptions?
AFAIK not at the moment but this should be possible to add this
functionality without too much knowledge of the code. managing the
difficult JCL 1.1 release is taking most of my time ATM so not sure when
i'd find time to code this.
anyone want to volunteer to create a patch?
(i'd be glad to answer questions)
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [betwixt] Exception suppression
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Tue, 2006-03-07 at 11:13 -0500, Igor Marakov wrote:
> I recently ran into the situation where betwixt is suppressing exceptions
> during the translation.
> I don't think it is a good idea.
> Enclosing application code should be aware that data that it expecting ain't
> coming. Here is the example of the unsuccessful translation of the SQLJ
> object that is coming from the DB and is supposed to be translated into the
> normal java bean. Translation fails due to SQLException, but application
> code is not getting any indication of it.
>
> Question: Is there the way to switch this behavior off or limit it to
> certain kinds of exceptions?
AFAIK not at the moment but this should be possible to add this
functionality without too much knowledge of the code. managing the
difficult JCL 1.1 release is taking most of my time ATM so not sure when
i'd find time to code this.
anyone want to volunteer to create a patch?
(i'd be glad to answer questions)
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
[betwixt] Exception suppression
Posted by Igor Marakov <ig...@ivmsystems.com>.
I recently ran into the situation where betwixt is suppressing exceptions
during the translation.
I don't think it is a good idea.
Enclosing application code should be aware that data that it expecting ain't
coming. Here is the example of the unsuccessful translation of the SQLJ
object that is coming from the DB and is supposed to be translated into the
normal java bean. Translation fails due to SQLException, but application
code is not getting any indication of it.
Question: Is there the way to switch this behavior off or limit it to
certain kinds of exceptions?
Thanks,
Igor
[DEBUG] com.my.framework.dao.bc4j.TranslatorImpl (translate) : START
translation com.my.framework.model.sqlj.MenuComponentC To java.util.List
[DEBUG] com.my.framework.dao.bc4j.TranslatorImpl (toXML) : Start toXML
translation
[ERROR] org.apache.commons.betwixt.expression.MethodExpression
(handleException) : [MethodExpression] Cannot evaluate expression
java.lang.reflect.InvocationTargetException
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:585)
at
org.apache.commons.betwixt.expression.MethodExpression.evaluate(MethodExpres
sion.java:61)
at
org.apache.commons.betwixt.expression.IteratorExpression.evaluate(IteratorEx
pression.java:53)
at
org.apache.commons.betwixt.io.AbstractBeanWriter.writeElementContent(Abstrac
tBeanWriter.java:924)
at
org.apache.commons.betwixt.io.AbstractBeanWriter.writeElement(AbstractBeanWr
iter.java:738)
at
org.apache.commons.betwixt.io.AbstractBeanWriter.writeBean(AbstractBeanWrite
r.java:374)
at
org.apache.commons.betwixt.io.AbstractBeanWriter.writeBean(AbstractBeanWrite
r.java:243)
at
org.apache.commons.betwixt.io.AbstractBeanWriter.write(AbstractBeanWriter.ja
va:144)
at org.apache.commons.betwixt.io.BeanWriter.write(BeanWriter.java:190)
at com.my.framework.dao.bc4j.TranslatorImpl.toXML(TranslatorImpl.java:180)
at
com.my.framework.dao.bc4j.TranslatorImpl.translate(TranslatorImpl.java:135)
at
com.my.framework.dao.bc4j.DAOProxyInvocationHandler.invoke(DAOProxyInvocatio
nHandler.java:117)
at $Proxy0.getMenuComponents(Unknown Source)
at com.my.framework.dao.TestDAO_1.doMenuTest(TestDAO_1.java:125)
at com.my.framework.dao.TestDAO_1.doTests(TestDAO_1.java:73)
at com.my.framework.dao.TestDAO_1.main(TestDAO_1.java:54)
Caused by: java.sql.SQLException: Fail to construct descriptor: Invalid
arguments
at
oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:112)
at
oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:146)
at oracle.sql.StructDescriptor.createDescriptor(StructDescriptor.java:155)
at oracle.sql.StructDescriptor.createDescriptor(StructDescriptor.java:130)
at oracle.jpub.runtime.MutableStruct.toDatum(MutableStruct.java:115)
at
com.my.framework.model.sqlj.MenuComponentT.toDatum(MenuComponentT.sqlj:110)
at oracle.jpub.runtime.Util._convertToOracle(Util.java:160)
at oracle.jpub.runtime.Util.convertToOracle(Util.java:146)
at oracle.jpub.runtime.MutableArray.getDatumElement(MutableArray.java:1273)
at oracle.jpub.runtime.MutableArray.getOracleArray(MutableArray.java:639)
at oracle.jpub.runtime.MutableArray.getObjectArray(MutableArray.java:810)
at oracle.jpub.runtime.MutableArray.getObjectArray(MutableArray.java:816)
at
com.my.framework.model.sqlj.MenuComponentC.getArray(MenuComponentC.java:76)
... 19 more
[DEBUG] com.my.framework.dao.bc4j.TranslatorImpl (toXML) : Resulting XML
<?xml version='1.0' ?>
<elements/>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
RE: [betwixt] Reader registration problem
Posted by Igor Marakov <ig...@ivmsystems.com>.
Hi Robert,
I use 0.7 binaries downloaded on 1/20
Changing one of the xmltags, something like "mybean" to "mibean", and
leaving the other one be, fixes the issue.
I'll see if I can try to get latest binaries.
Thanks,
igor
-----Original Message-----
From: robert burrell donkin [mailto:robertburrelldonkin@blueyonder.co.uk]
Sent: Wednesday, March 01, 2006 5:55 PM
To: Jakarta Commons Users List
Subject: Re: [betwixt] Reader registration problem
hi igor
are you using the latest code (from a recently nightly or subversion)?
if not, could you retry using the latest code?
if you can supply a test case (please attach it to a bugzilla)
demonstrating the issue, i'll see if i can fix it.
- robert
On Wed, 2006-03-01 at 16:40 -0500, Igor Marakov wrote:
> I wonder if anybody had seen this:
>
> When reader registration map is created for incoming XML translation it is
> created with tag/class pairs.
>
> I ran today into the situations when IF an element of the registration
> HashMap in the reader has NOT NULL "next" element, then during the
> translation instance of the wrong class is created.
>
> Unfortunately I cannot provide a real example but, here is what happens:
>
> ** registration process **
> ...
> reader.registerBeanClass("mybean", com.rather.long.class.name.Mybean);
> reader.registerBeanClass("mybeanSimilarName",
> com.rather.long.class.name.MybeanSimilarName);
> ...
>
> What I see in debugger:
> ** resulting HashMap ** inside the reader ( registeredClasses )
> HashMap$Entry [xx] value com.rather.long.class.name.Mybean
> Field "key" com.rather.long.class.name.Mybean
> Field "next" HashMap$Entry com.rather.long.class.name.MybeanSimilarName
>
>
> ** On translation of the XML element "mybeanSimilarName"
>
> ** Bean factory ( I have my own chained in ) **
> reports two beans being instantiated:
> com.rather.long.class.name.Mybean
> com.rather.long.class.name.MybeanSimilarName
>
>
> ** resulting object is **
> com.rather.long.class.name.Mybean
>
>
> Thanks,
> Igor
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [betwixt] Reader registration problem
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
hi igor
are you using the latest code (from a recently nightly or subversion)?
if not, could you retry using the latest code?
if you can supply a test case (please attach it to a bugzilla)
demonstrating the issue, i'll see if i can fix it.
- robert
On Wed, 2006-03-01 at 16:40 -0500, Igor Marakov wrote:
> I wonder if anybody had seen this:
>
> When reader registration map is created for incoming XML translation it is
> created with tag/class pairs.
>
> I ran today into the situations when IF an element of the registration
> HashMap in the reader has NOT NULL "next" element, then during the
> translation instance of the wrong class is created.
>
> Unfortunately I cannot provide a real example but, here is what happens:
>
> ** registration process **
> ...
> reader.registerBeanClass("mybean", com.rather.long.class.name.Mybean);
> reader.registerBeanClass("mybeanSimilarName",
> com.rather.long.class.name.MybeanSimilarName);
> ...
>
> What I see in debugger:
> ** resulting HashMap ** inside the reader ( registeredClasses )
> HashMap$Entry [xx] value com.rather.long.class.name.Mybean
> Field "key" com.rather.long.class.name.Mybean
> Field "next" HashMap$Entry com.rather.long.class.name.MybeanSimilarName
>
>
> ** On translation of the XML element "mybeanSimilarName"
>
> ** Bean factory ( I have my own chained in ) **
> reports two beans being instantiated:
> com.rather.long.class.name.Mybean
> com.rather.long.class.name.MybeanSimilarName
>
>
> ** resulting object is **
> com.rather.long.class.name.Mybean
>
>
> Thanks,
> Igor
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org