You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user-java@ibatis.apache.org by Zsolt Koppany <zk...@intland.com> on 2008/10/14 11:34:24 UTC

2.3.4.726 and XmlConverter

Hi,

XmlConverter doesn't seem to be available in 2.3.4.726.

We extend that class to pre-process xml files.

What should we use instead of XmlConverter?

Zsolt



RE: 2.3.4.726 and XmlConverter

Posted by Niels Beekman <n....@wis.nl>.
Hit Zsolt,

 

That's probably a bug, iBATIS should check properties for that attribute
as well. Maybe you can file an issue in JIRA for it.

 

Niels

________________________________

From: Zsolt Koppany [mailto:zkoppanylist@intland.com] 
Sent: Saturday, October 18, 2008 10:52 PM
To: user-java@ibatis.apache.org
Subject: RE: 2.3.4.726 and XmlConverter

 

Niels,

 

For the block below I get an exception. The property SELECTKEY_TYPE is
definitely set to "post".

 

com.ibatis.common.xml.NodeletException: Error parsing XML.  Cause:
java.lang.RuntimeException: Error parsing XPath '/sqlMapConfig/sqlMap'.
Cause: com.ibatis.common.xml.NodeletException: Error parsing XML.
Cause: org.xml.sax.SAXParseException: Attribute "type" with value
"${SELECTKEY_TYPE}" must have a value from the list "pre post ".

            at
com.ibatis.sqlmap.engine.builder.xml.SqlMapConfigParser.parse(SqlMapConf
igParser.java:89)

            at
com.ibatis.sqlmap.engine.builder.xml.SqlMapConfigParser.parse(SqlMapConf
igParser.java:75)

            at
com.intland.codebeamer.persistence.rdbms.DataAccessSupport.getSqlMapInst
ance(DataAccessSupport.java:152)

            at
com.intland.codebeamer.persistence.dao.AbstractDao.getSqlMapInstance(Abs
tractDao.java:70)

            at
com.intland.codebeamer.persistence.dao.AbstractDao.create(AbstractDao.ja
va:83)

 

 

 

  <insert id="createTrackerItem" parameterClass="trackerItemDto">

            INSERT INTO task

              ( ${PRE_ID_COMMENT}id,${POST_ID_COMMENT} type_id,
parent_id, status_id, priority,

                        submitted_at, submitted_by, modified_at,
modified_by, assigned_at, approver_user_id,

                        summary, details, ishtml, start_date,
close_date, estimated_hours, spent_hours,

                        nr_of_attachments, closed_at, indexed,
isdeleted)

            VALUES

              ( ${PRE_ID_COMMENT}#id#,${POST_ID_COMMENT} #tracker.id#,
#parent.id#, #status.id#, #priority#,

                #submittedAt#, #submitter.id#, #modifiedAt#,
#modifier.id#, #assignedAt#, #approver#,

                        #name#, #description#, #descriptionFormat#,
#startDate#, #endDate#, #estimatedHours#, #spentHours#,

                        #noOfAttachments#, #closedAt#, #indexed#,
#deleted#)

            <selectKey resultClass="java.lang.Integer" keyProperty="id"
type="${SELECTKEY_TYPE}" >

 
${SELECTKEY_BEFORE_TABLE_NAME_SQL_PART}task${SELECTKEY_AFTER_TABLE_NAME_
SQL_PART}

            </selectKey>

  </insert>

 

Zsolt 

________________________________

From: Niels Beekman [mailto:n.beekman@wis.nl] 
Sent: Saturday, October 18, 2008 12:18 PM
To: user-java@ibatis.apache.org
Subject: RE: 2.3.4.726 and XmlConverter

 

I'm talking about DaoManagerBuilder.buildDaoManager or
SqlMapClientBuilder.buildSqlMapClient, these classes have an overload
that takes a Properties instance. These properties can then be used in
all queries, regardless of parameter classes.

 

Niels

________________________________

From: Zsolt Koppany [mailto:zkoppanylist@intland.com] 
Sent: Saturday, October 18, 2008 10:01 AM
To: user-java@ibatis.apache.org
Subject: RE: 2.3.4.726 and XmlConverter

 

Neils,

 

as I described it in a previous email we know this option with
properties, but that would me that we should modify a lot of classes
additionally where we pass a class as property we cannot set properties.

 

Zsolt 

________________________________

From: Niels Beekman [mailto:n.beekman@wis.nl] 
Sent: Friday, October 17, 2008 8:57 AM
To: user-java@ibatis.apache.org
Subject: RE: 2.3.4.726 and XmlConverter

 

You could easily do this with properties, unless you are connecting to
databases on the fly. Search the archives for some examples of this. We
use this for purposes similar like yours.

 

Niels

________________________________

From: Zsolt Koppany [mailto:zkoppanylist@intland.com] 
Sent: Friday, October 17, 2008 6:41 AM
To: user-java@ibatis.apache.org
Subject: RE: 2.3.4.726 and XmlConverter

 

I'm not sure whether my problem is clear. Please check the code below
(just an example). The expression ${INT_NULL_FIELD_VALUE} has different
value on different database thus during the xml file is read we transfer
the expression into a database dependent string.

 

I understand that we could do that setting the property from Dao but in
this case the Dao would be database dependent what we don't like.

 

Zsolt

 

            <select id="loadBlob" parameterClass="java.util.Map"
resultMap="inputStreamResult" >

                         SELECT $queryParams.fileNameField$ as fileName,

                                     <isEqual property="fetchBlob"
compareValue="true">

 
LENGTH($queryParams.blobFieldName$) AS length,

                                                 $blobFetchStmt$ AS
blobData

                                     </isEqual>

                                     <!-- even when no need to fetch
blob, still have to select a null value, to get the resultmaps satisfied
-->

                                     <isEqual property="fetchBlob"
compareValue="false">

                                                 ${INT_NULL_FIELD_VALUE}
AS length,

                                                 NULL AS blobData

                                     </isEqual>

                           FROM $queryParams.tableName$

                          WHERE $queryParams.idFieldName$=#id#

            </select>

 

Zsolt 

________________________________

From: Clinton Begin [mailto:clinton.begin@gmail.com] 
Sent: Friday, October 17, 2008 4:09 AM
To: user-java@ibatis.apache.org
Subject: Re: 2.3.4.726 and XmlConverter

 

I don't think Zsolt is talking about the XML results/parameters support
in iBATIS.  XMLConverter was a class used to literally translate iBATIS
1.x mapping files into iBATIS 2.x mapping files using XSLT. It allowed
either runtime conversion or batch conversion.  

 

Zsolt could use the old version to do the one-time conversion of all of
his files if he wants, but it sounds like he is extending the class for
some reason, in which case he could just grab the code and make it his
own.

 

Clinton

On Thu, Oct 16, 2008 at 5:02 PM, <Ch...@sybase.com>
wrote:


As a suggestion Zsolt, iBatis does OR mapping extremely well. What you
are looking for is something that will map Objects into XML extremely
well. Why not take a look at XStream by thoughtworks. I'm using their
library for several projects pertaining to Object -> XML and it handles
them exceptionally well. And by utilizing a library like this it will
give you a clean separation of concern as well as better control over
the XML that you want to generate. 

http://xstream.codehaus.org/ 

"Clinton Begin" <cl...@gmail.com> 

10/16/2008 03:42 PM 

Please respond to 


user-java@ibatis.apache.org

To

user-java@ibatis.apache.org 

cc

 

Subject

Re: 2.3.4.726 and XmlConverter

 

 

 

 

 

 




Zsolt, 

This feature is really old and was only there to support 1.x clients
during the transition to 2.x.  If you're still have 1.x maps, it might
be a good time to move them.  Otherwise, consider it a deprecated
feature.  Thus, the long-term solution is for you to either adopt the
code as your own, or migrate your SQL mapping files. 

cheers
Clinton

On Thu, Oct 16, 2008 at 2:56 PM, Zsolt Koppany
<zk...@intland.com> wrote: 
Larry,

are there better options that will work long term?

What is the recommended way today?

Zsolt 

> -----Original Message-----
> From: Larry Meadors [mailto:larry.meadors@gmail.com]
> Sent: Thursday, October 16, 2008 3:55 PM
> To: user-java@ibatis.apache.org
> Subject: Re: 2.3.4.726 and XmlConverter
> 
> Two options:
>
>  - stick with the older version of ibatis that has all the parts you
need
>  - extract the parts you need from the older version of ibatis and use
> them alongside the new release
>
> Larry

 


RE: 2.3.4.726 and XmlConverter

Posted by Zsolt Koppany <zk...@intland.com>.
Niels,

 

For the block below I get an exception. The property SELECTKEY_TYPE is
definitely set to "post".

 

com.ibatis.common.xml.NodeletException: Error parsing XML.  Cause:
java.lang.RuntimeException: Error parsing XPath '/sqlMapConfig/sqlMap'.
Cause: com.ibatis.common.xml.NodeletException: Error parsing XML.  Cause:
org.xml.sax.SAXParseException: Attribute "type" with value
"${SELECTKEY_TYPE}" must have a value from the list "pre post ".

            at
com.ibatis.sqlmap.engine.builder.xml.SqlMapConfigParser.parse(SqlMapConfigPa
rser.java:89)

            at
com.ibatis.sqlmap.engine.builder.xml.SqlMapConfigParser.parse(SqlMapConfigPa
rser.java:75)

            at
com.intland.codebeamer.persistence.rdbms.DataAccessSupport.getSqlMapInstance
(DataAccessSupport.java:152)

            at
com.intland.codebeamer.persistence.dao.AbstractDao.getSqlMapInstance(Abstrac
tDao.java:70)

            at
com.intland.codebeamer.persistence.dao.AbstractDao.create(AbstractDao.java:8
3)

 

 

 

  <insert id="createTrackerItem" parameterClass="trackerItemDto">

            INSERT INTO task

              ( ${PRE_ID_COMMENT}id,${POST_ID_COMMENT} type_id, parent_id,
status_id, priority,

                        submitted_at, submitted_by, modified_at,
modified_by, assigned_at, approver_user_id,

                        summary, details, ishtml, start_date, close_date,
estimated_hours, spent_hours,

                        nr_of_attachments, closed_at, indexed, isdeleted)

            VALUES

              ( ${PRE_ID_COMMENT}#id#,${POST_ID_COMMENT} #tracker.id#,
#parent.id#, #status.id#, #priority#,

                #submittedAt#, #submitter.id#, #modifiedAt#, #modifier.id#,
#assignedAt#, #approver#,

                        #name#, #description#, #descriptionFormat#,
#startDate#, #endDate#, #estimatedHours#, #spentHours#,

                        #noOfAttachments#, #closedAt#, #indexed#, #deleted#)

            <selectKey resultClass="java.lang.Integer" keyProperty="id"
type="${SELECTKEY_TYPE}" >

 
${SELECTKEY_BEFORE_TABLE_NAME_SQL_PART}task${SELECTKEY_AFTER_TABLE_NAME_SQL_
PART}

            </selectKey>

  </insert>

 

Zsolt 

  _____  

From: Niels Beekman [mailto:n.beekman@wis.nl] 
Sent: Saturday, October 18, 2008 12:18 PM
To: user-java@ibatis.apache.org
Subject: RE: 2.3.4.726 and XmlConverter

 

I'm talking about DaoManagerBuilder.buildDaoManager or
SqlMapClientBuilder.buildSqlMapClient, these classes have an overload that
takes a Properties instance. These properties can then be used in all
queries, regardless of parameter classes.

 

Niels

  _____  

From: Zsolt Koppany [mailto:zkoppanylist@intland.com] 
Sent: Saturday, October 18, 2008 10:01 AM
To: user-java@ibatis.apache.org
Subject: RE: 2.3.4.726 and XmlConverter

 

Neils,

 

as I described it in a previous email we know this option with properties,
but that would me that we should modify a lot of classes additionally where
we pass a class as property we cannot set properties.

 

Zsolt 

  _____  

From: Niels Beekman [mailto:n.beekman@wis.nl] 
Sent: Friday, October 17, 2008 8:57 AM
To: user-java@ibatis.apache.org
Subject: RE: 2.3.4.726 and XmlConverter

 

You could easily do this with properties, unless you are connecting to
databases on the fly. Search the archives for some examples of this. We use
this for purposes similar like yours.

 

Niels

  _____  

From: Zsolt Koppany [mailto:zkoppanylist@intland.com] 
Sent: Friday, October 17, 2008 6:41 AM
To: user-java@ibatis.apache.org
Subject: RE: 2.3.4.726 and XmlConverter

 

I'm not sure whether my problem is clear. Please check the code below (just
an example). The expression ${INT_NULL_FIELD_VALUE} has different value on
different database thus during the xml file is read we transfer the
expression into a database dependent string.

 

I understand that we could do that setting the property from Dao but in this
case the Dao would be database dependent what we don't like.

 

Zsolt

 

            <select id="loadBlob" parameterClass="java.util.Map"
resultMap="inputStreamResult" >

                         SELECT $queryParams.fileNameField$ as fileName,

                                     <isEqual property="fetchBlob"
compareValue="true">

 
LENGTH($queryParams.blobFieldName$) AS length,

                                                 $blobFetchStmt$ AS blobData

                                     </isEqual>

                                     <!-- even when no need to fetch blob,
still have to select a null value, to get the resultmaps satisfied -->

                                     <isEqual property="fetchBlob"
compareValue="false">

                                                 ${INT_NULL_FIELD_VALUE} AS
length,

                                                 NULL AS blobData

                                     </isEqual>

                           FROM $queryParams.tableName$

                          WHERE $queryParams.idFieldName$=#id#

            </select>

 

Zsolt 

  _____  

From: Clinton Begin [mailto:clinton.begin@gmail.com] 
Sent: Friday, October 17, 2008 4:09 AM
To: user-java@ibatis.apache.org
Subject: Re: 2.3.4.726 and XmlConverter

 

I don't think Zsolt is talking about the XML results/parameters support in
iBATIS.  XMLConverter was a class used to literally translate iBATIS 1.x
mapping files into iBATIS 2.x mapping files using XSLT. It allowed either
runtime conversion or batch conversion.  

 

Zsolt could use the old version to do the one-time conversion of all of his
files if he wants, but it sounds like he is extending the class for some
reason, in which case he could just grab the code and make it his own.

 

Clinton

On Thu, Oct 16, 2008 at 5:02 PM, <Ch...@sybase.com> wrote:


As a suggestion Zsolt, iBatis does OR mapping extremely well. What you are
looking for is something that will map Objects into XML extremely well. Why
not take a look at XStream by thoughtworks. I'm using their library for
several projects pertaining to Object -> XML and it handles them
exceptionally well. And by utilizing a library like this it will give you a
clean separation of concern as well as better control over the XML that you
want to generate. 

http://xstream.codehaus.org/ 


"Clinton Begin" <cl...@gmail.com> 

10/16/2008 03:42 PM 


Please respond to 


user-java@ibatis.apache.org


To

user-java@ibatis.apache.org 


cc

 


Subject

Re: 2.3.4.726 and XmlConverter


 

 

 


 

 

 




Zsolt, 

This feature is really old and was only there to support 1.x clients during
the transition to 2.x.  If you're still have 1.x maps, it might be a good
time to move them.  Otherwise, consider it a deprecated feature.  Thus, the
long-term solution is for you to either adopt the code as your own, or
migrate your SQL mapping files. 

cheers
Clinton

On Thu, Oct 16, 2008 at 2:56 PM, Zsolt Koppany <zk...@intland.com>
wrote: 
Larry,

are there better options that will work long term?

What is the recommended way today?

Zsolt 

> -----Original Message-----
> From: Larry Meadors [mailto:larry.meadors@gmail.com]
> Sent: Thursday, October 16, 2008 3:55 PM
> To: user-java@ibatis.apache.org
> Subject: Re: 2.3.4.726 and XmlConverter
> 
> Two options:
>
>  - stick with the older version of ibatis that has all the parts you need
>  - extract the parts you need from the older version of ibatis and use
> them alongside the new release
>
> Larry

 


RE: 2.3.4.726 and XmlConverter

Posted by Niels Beekman <n....@wis.nl>.
I'm talking about DaoManagerBuilder.buildDaoManager or
SqlMapClientBuilder.buildSqlMapClient, these classes have an overload
that takes a Properties instance. These properties can then be used in
all queries, regardless of parameter classes.

 

Niels

________________________________

From: Zsolt Koppany [mailto:zkoppanylist@intland.com] 
Sent: Saturday, October 18, 2008 10:01 AM
To: user-java@ibatis.apache.org
Subject: RE: 2.3.4.726 and XmlConverter

 

Neils,

 

as I described it in a previous email we know this option with
properties, but that would me that we should modify a lot of classes
additionally where we pass a class as property we cannot set properties.

 

Zsolt 

________________________________

From: Niels Beekman [mailto:n.beekman@wis.nl] 
Sent: Friday, October 17, 2008 8:57 AM
To: user-java@ibatis.apache.org
Subject: RE: 2.3.4.726 and XmlConverter

 

You could easily do this with properties, unless you are connecting to
databases on the fly. Search the archives for some examples of this. We
use this for purposes similar like yours.

 

Niels

________________________________

From: Zsolt Koppany [mailto:zkoppanylist@intland.com] 
Sent: Friday, October 17, 2008 6:41 AM
To: user-java@ibatis.apache.org
Subject: RE: 2.3.4.726 and XmlConverter

 

I'm not sure whether my problem is clear. Please check the code below
(just an example). The expression ${INT_NULL_FIELD_VALUE} has different
value on different database thus during the xml file is read we transfer
the expression into a database dependent string.

 

I understand that we could do that setting the property from Dao but in
this case the Dao would be database dependent what we don't like.

 

Zsolt

 

            <select id="loadBlob" parameterClass="java.util.Map"
resultMap="inputStreamResult" >

                         SELECT $queryParams.fileNameField$ as fileName,

                                     <isEqual property="fetchBlob"
compareValue="true">

 
LENGTH($queryParams.blobFieldName$) AS length,

                                                 $blobFetchStmt$ AS
blobData

                                     </isEqual>

                                     <!-- even when no need to fetch
blob, still have to select a null value, to get the resultmaps satisfied
-->

                                     <isEqual property="fetchBlob"
compareValue="false">

                                                 ${INT_NULL_FIELD_VALUE}
AS length,

                                                 NULL AS blobData

                                     </isEqual>

                           FROM $queryParams.tableName$

                          WHERE $queryParams.idFieldName$=#id#

            </select>

 

Zsolt 

________________________________

From: Clinton Begin [mailto:clinton.begin@gmail.com] 
Sent: Friday, October 17, 2008 4:09 AM
To: user-java@ibatis.apache.org
Subject: Re: 2.3.4.726 and XmlConverter

 

I don't think Zsolt is talking about the XML results/parameters support
in iBATIS.  XMLConverter was a class used to literally translate iBATIS
1.x mapping files into iBATIS 2.x mapping files using XSLT. It allowed
either runtime conversion or batch conversion.  

 

Zsolt could use the old version to do the one-time conversion of all of
his files if he wants, but it sounds like he is extending the class for
some reason, in which case he could just grab the code and make it his
own.

 

Clinton

On Thu, Oct 16, 2008 at 5:02 PM, <Ch...@sybase.com>
wrote:


As a suggestion Zsolt, iBatis does OR mapping extremely well. What you
are looking for is something that will map Objects into XML extremely
well. Why not take a look at XStream by thoughtworks. I'm using their
library for several projects pertaining to Object -> XML and it handles
them exceptionally well. And by utilizing a library like this it will
give you a clean separation of concern as well as better control over
the XML that you want to generate. 

http://xstream.codehaus.org/ 

"Clinton Begin" <cl...@gmail.com> 

10/16/2008 03:42 PM 

Please respond to 


user-java@ibatis.apache.org

To

user-java@ibatis.apache.org 

cc

 

Subject

Re: 2.3.4.726 and XmlConverter

 

 

 

 

 

 




Zsolt, 

This feature is really old and was only there to support 1.x clients
during the transition to 2.x.  If you're still have 1.x maps, it might
be a good time to move them.  Otherwise, consider it a deprecated
feature.  Thus, the long-term solution is for you to either adopt the
code as your own, or migrate your SQL mapping files. 

cheers
Clinton

On Thu, Oct 16, 2008 at 2:56 PM, Zsolt Koppany
<zk...@intland.com> wrote: 
Larry,

are there better options that will work long term?

What is the recommended way today?

Zsolt 

> -----Original Message-----
> From: Larry Meadors [mailto:larry.meadors@gmail.com]
> Sent: Thursday, October 16, 2008 3:55 PM
> To: user-java@ibatis.apache.org
> Subject: Re: 2.3.4.726 and XmlConverter
> 
> Two options:
>
>  - stick with the older version of ibatis that has all the parts you
need
>  - extract the parts you need from the older version of ibatis and use
> them alongside the new release
>
> Larry

 


RE: 2.3.4.726 and XmlConverter

Posted by Zsolt Koppany <zk...@intland.com>.
Neils,

 

as I described it in a previous email we know this option with properties,
but that would me that we should modify a lot of classes additionally where
we pass a class as property we cannot set properties.

 

Zsolt 

  _____  

From: Niels Beekman [mailto:n.beekman@wis.nl] 
Sent: Friday, October 17, 2008 8:57 AM
To: user-java@ibatis.apache.org
Subject: RE: 2.3.4.726 and XmlConverter

 

You could easily do this with properties, unless you are connecting to
databases on the fly. Search the archives for some examples of this. We use
this for purposes similar like yours.

 

Niels

  _____  

From: Zsolt Koppany [mailto:zkoppanylist@intland.com] 
Sent: Friday, October 17, 2008 6:41 AM
To: user-java@ibatis.apache.org
Subject: RE: 2.3.4.726 and XmlConverter

 

I'm not sure whether my problem is clear. Please check the code below (just
an example). The expression ${INT_NULL_FIELD_VALUE} has different value on
different database thus during the xml file is read we transfer the
expression into a database dependent string.

 

I understand that we could do that setting the property from Dao but in this
case the Dao would be database dependent what we don't like.

 

Zsolt

 

            <select id="loadBlob" parameterClass="java.util.Map"
resultMap="inputStreamResult" >

                         SELECT $queryParams.fileNameField$ as fileName,

                                     <isEqual property="fetchBlob"
compareValue="true">

 
LENGTH($queryParams.blobFieldName$) AS length,

                                                 $blobFetchStmt$ AS blobData

                                     </isEqual>

                                     <!-- even when no need to fetch blob,
still have to select a null value, to get the resultmaps satisfied -->

                                     <isEqual property="fetchBlob"
compareValue="false">

                                                 ${INT_NULL_FIELD_VALUE} AS
length,

                                                 NULL AS blobData

                                     </isEqual>

                           FROM $queryParams.tableName$

                          WHERE $queryParams.idFieldName$=#id#

            </select>

 

Zsolt 

  _____  

From: Clinton Begin [mailto:clinton.begin@gmail.com] 
Sent: Friday, October 17, 2008 4:09 AM
To: user-java@ibatis.apache.org
Subject: Re: 2.3.4.726 and XmlConverter

 

I don't think Zsolt is talking about the XML results/parameters support in
iBATIS.  XMLConverter was a class used to literally translate iBATIS 1.x
mapping files into iBATIS 2.x mapping files using XSLT. It allowed either
runtime conversion or batch conversion.  

 

Zsolt could use the old version to do the one-time conversion of all of his
files if he wants, but it sounds like he is extending the class for some
reason, in which case he could just grab the code and make it his own.

 

Clinton

On Thu, Oct 16, 2008 at 5:02 PM, <Ch...@sybase.com> wrote:


As a suggestion Zsolt, iBatis does OR mapping extremely well. What you are
looking for is something that will map Objects into XML extremely well. Why
not take a look at XStream by thoughtworks. I'm using their library for
several projects pertaining to Object -> XML and it handles them
exceptionally well. And by utilizing a library like this it will give you a
clean separation of concern as well as better control over the XML that you
want to generate. 

http://xstream.codehaus.org/ 


"Clinton Begin" <cl...@gmail.com> 

10/16/2008 03:42 PM 


Please respond to 


user-java@ibatis.apache.org


To

user-java@ibatis.apache.org 


cc

 


Subject

Re: 2.3.4.726 and XmlConverter


 

 

 


 

 

 




Zsolt, 

This feature is really old and was only there to support 1.x clients during
the transition to 2.x.  If you're still have 1.x maps, it might be a good
time to move them.  Otherwise, consider it a deprecated feature.  Thus, the
long-term solution is for you to either adopt the code as your own, or
migrate your SQL mapping files. 

cheers
Clinton

On Thu, Oct 16, 2008 at 2:56 PM, Zsolt Koppany <zk...@intland.com>
wrote: 
Larry,

are there better options that will work long term?

What is the recommended way today?

Zsolt 

> -----Original Message-----
> From: Larry Meadors [mailto:larry.meadors@gmail.com]
> Sent: Thursday, October 16, 2008 3:55 PM
> To: user-java@ibatis.apache.org
> Subject: Re: 2.3.4.726 and XmlConverter
> 
> Two options:
>
>  - stick with the older version of ibatis that has all the parts you need
>  - extract the parts you need from the older version of ibatis and use
> them alongside the new release
>
> Larry

 


RE: 2.3.4.726 and XmlConverter

Posted by Niels Beekman <n....@wis.nl>.
You could easily do this with properties, unless you are connecting to
databases on the fly. Search the archives for some examples of this. We
use this for purposes similar like yours.

 

Niels

________________________________

From: Zsolt Koppany [mailto:zkoppanylist@intland.com] 
Sent: Friday, October 17, 2008 6:41 AM
To: user-java@ibatis.apache.org
Subject: RE: 2.3.4.726 and XmlConverter

 

I'm not sure whether my problem is clear. Please check the code below
(just an example). The expression ${INT_NULL_FIELD_VALUE} has different
value on different database thus during the xml file is read we transfer
the expression into a database dependent string.

 

I understand that we could do that setting the property from Dao but in
this case the Dao would be database dependent what we don't like.

 

Zsolt

 

            <select id="loadBlob" parameterClass="java.util.Map"
resultMap="inputStreamResult" >

                         SELECT $queryParams.fileNameField$ as fileName,

                                     <isEqual property="fetchBlob"
compareValue="true">

 
LENGTH($queryParams.blobFieldName$) AS length,

                                                 $blobFetchStmt$ AS
blobData

                                     </isEqual>

                                     <!-- even when no need to fetch
blob, still have to select a null value, to get the resultmaps satisfied
-->

                                     <isEqual property="fetchBlob"
compareValue="false">

                                                 ${INT_NULL_FIELD_VALUE}
AS length,

                                                 NULL AS blobData

                                     </isEqual>

                           FROM $queryParams.tableName$

                          WHERE $queryParams.idFieldName$=#id#

            </select>

 

Zsolt 

________________________________

From: Clinton Begin [mailto:clinton.begin@gmail.com] 
Sent: Friday, October 17, 2008 4:09 AM
To: user-java@ibatis.apache.org
Subject: Re: 2.3.4.726 and XmlConverter

 

I don't think Zsolt is talking about the XML results/parameters support
in iBATIS.  XMLConverter was a class used to literally translate iBATIS
1.x mapping files into iBATIS 2.x mapping files using XSLT. It allowed
either runtime conversion or batch conversion.  

 

Zsolt could use the old version to do the one-time conversion of all of
his files if he wants, but it sounds like he is extending the class for
some reason, in which case he could just grab the code and make it his
own.

 

Clinton

On Thu, Oct 16, 2008 at 5:02 PM, <Ch...@sybase.com>
wrote:


As a suggestion Zsolt, iBatis does OR mapping extremely well. What you
are looking for is something that will map Objects into XML extremely
well. Why not take a look at XStream by thoughtworks. I'm using their
library for several projects pertaining to Object -> XML and it handles
them exceptionally well. And by utilizing a library like this it will
give you a clean separation of concern as well as better control over
the XML that you want to generate. 

http://xstream.codehaus.org/ 



"Clinton Begin" <cl...@gmail.com> 

10/16/2008 03:42 PM 

Please respond to 


user-java@ibatis.apache.org

To

user-java@ibatis.apache.org 

cc

 

Subject

Re: 2.3.4.726 and XmlConverter

 

 

 

 

 

 




Zsolt, 

This feature is really old and was only there to support 1.x clients
during the transition to 2.x.  If you're still have 1.x maps, it might
be a good time to move them.  Otherwise, consider it a deprecated
feature.  Thus, the long-term solution is for you to either adopt the
code as your own, or migrate your SQL mapping files. 

cheers
Clinton

On Thu, Oct 16, 2008 at 2:56 PM, Zsolt Koppany
<zk...@intland.com> wrote: 
Larry,

are there better options that will work long term?

What is the recommended way today?

Zsolt 

> -----Original Message-----
> From: Larry Meadors [mailto:larry.meadors@gmail.com]
> Sent: Thursday, October 16, 2008 3:55 PM
> To: user-java@ibatis.apache.org
> Subject: Re: 2.3.4.726 and XmlConverter
> 
> Two options:
>
>  - stick with the older version of ibatis that has all the parts you
need
>  - extract the parts you need from the older version of ibatis and use
> them alongside the new release
>
> Larry

 


RE: 2.3.4.726 and XmlConverter

Posted by Zsolt Koppany <zk...@intland.com>.
I'm not sure whether my problem is clear. Please check the code below (just
an example). The expression ${INT_NULL_FIELD_VALUE} has different value on
different database thus during the xml file is read we transfer the
expression into a database dependent string.

 

I understand that we could do that setting the property from Dao but in this
case the Dao would be database dependent what we don't like.

 

Zsolt

 

            <select id="loadBlob" parameterClass="java.util.Map"
resultMap="inputStreamResult" >

                         SELECT $queryParams.fileNameField$ as fileName,

                                     <isEqual property="fetchBlob"
compareValue="true">

 
LENGTH($queryParams.blobFieldName$) AS length,

                                                 $blobFetchStmt$ AS blobData

                                     </isEqual>

                                     <!-- even when no need to fetch blob,
still have to select a null value, to get the resultmaps satisfied -->

                                     <isEqual property="fetchBlob"
compareValue="false">

                                                 ${INT_NULL_FIELD_VALUE} AS
length,

                                                 NULL AS blobData

                                     </isEqual>

                           FROM $queryParams.tableName$

                          WHERE $queryParams.idFieldName$=#id#

            </select>

 

Zsolt 

  _____  

From: Clinton Begin [mailto:clinton.begin@gmail.com] 
Sent: Friday, October 17, 2008 4:09 AM
To: user-java@ibatis.apache.org
Subject: Re: 2.3.4.726 and XmlConverter

 

I don't think Zsolt is talking about the XML results/parameters support in
iBATIS.  XMLConverter was a class used to literally translate iBATIS 1.x
mapping files into iBATIS 2.x mapping files using XSLT. It allowed either
runtime conversion or batch conversion.  

 

Zsolt could use the old version to do the one-time conversion of all of his
files if he wants, but it sounds like he is extending the class for some
reason, in which case he could just grab the code and make it his own.

 

Clinton

On Thu, Oct 16, 2008 at 5:02 PM, <Ch...@sybase.com> wrote:


As a suggestion Zsolt, iBatis does OR mapping extremely well. What you are
looking for is something that will map Objects into XML extremely well. Why
not take a look at XStream by thoughtworks. I'm using their library for
several projects pertaining to Object -> XML and it handles them
exceptionally well. And by utilizing a library like this it will give you a
clean separation of concern as well as better control over the XML that you
want to generate. 

http://xstream.codehaus.org/ 





"Clinton Begin" <cl...@gmail.com> 

10/16/2008 03:42 PM 


Please respond to 


user-java@ibatis.apache.org


To

user-java@ibatis.apache.org 


cc

 


Subject

Re: 2.3.4.726 and XmlConverter


 

 

 


 

 

 




Zsolt, 

This feature is really old and was only there to support 1.x clients during
the transition to 2.x.  If you're still have 1.x maps, it might be a good
time to move them.  Otherwise, consider it a deprecated feature.  Thus, the
long-term solution is for you to either adopt the code as your own, or
migrate your SQL mapping files. 

cheers
Clinton

On Thu, Oct 16, 2008 at 2:56 PM, Zsolt Koppany <zk...@intland.com>
wrote: 
Larry,

are there better options that will work long term?

What is the recommended way today?

Zsolt 

> -----Original Message-----
> From: Larry Meadors [mailto:larry.meadors@gmail.com]
> Sent: Thursday, October 16, 2008 3:55 PM
> To: user-java@ibatis.apache.org
> Subject: Re: 2.3.4.726 and XmlConverter
> 
> Two options:
>
>  - stick with the older version of ibatis that has all the parts you need
>  - extract the parts you need from the older version of ibatis and use
> them alongside the new release
>
> Larry



 


RE: queryForList()

Posted by Poitras Christian <Ch...@ircm.qc.ca>.
That is, unfortunately, dependent on your database.
On MySQL it would look like this.

SELECT *
FROM SomeTable
LIMIT skipCount, maxCount

Limiting number of results in the queryForList can force your database to return all 10198 records (depending on java connector) even if iBATIS will remove exceeding elements from the list before returning from call.
Considering this problem, RowHandler is the best solution if you don't want to become database dependent.

Using both solution combined can also be a good idea depending on what you want to acheive.

Christian


-----Original Message-----
From: John Chien [mailto:john.chien@ncmail.net]
Sent: Friday, October 17, 2008 2:01 PM
To: user-java@ibatis.apache.org
Subject: Re: queryForList()

Christian:

1)  I look at the RowHandler interface.
Eventually, it will return the whole list. That means it will return a list of 10198 records.
That is exactly I tried to avoid. I do not want it to return me such a big list.

I know that the RowHandler itself will try to to the insertion for me.
However, I have no idea of how many insertion has been executed, unless I wait for it to return me such a big list.

2) How can I put the maxCount in the SQL statement ?
    Although the SQL statement will return me a list of objects, how can I put it in SQL statement to return me a range of objects while I do not have
    idea of how many objects will be returned.

Thanks,

John Chien

Poitras Christian wrote:
> It would be better if your code would do one of the following.
> 1) Use a RowHandler. This is optimized for these kind of queries.
> 2) Use maxCount in your SQL statement and not in queryForList. Some connectors don't use maximum count to limit the number of results sent from the database. In these cases limiting number of results in the SQL statement is your only choice.
>
> I would go with solution 1 unless you cannot use a RowHandler.
>
> Christian
>
>
> -----Original Message-----
> From: John Chien [mailto:john.chien@ncmail.net]
> Sent: Friday, October 17, 2008 11:02 AM
> To: user-java@ibatis.apache.org
> Subject: queryForList()
>
>
> Dear Sir:
>
> I used the SQLMAP' s API queryForList to get data back from database.
> There are many data in database, so I the one that has four input parameters.
> The SQLMAP XML syntax should return me 10198 records, if runs without loop.
> I have already tested this by plugin the values.
>
> However, I have it runs in loop and bring back 500 records every time.
> It should run 21 times. However, it returns null at the 12 loops (very consistently. I try many times) I am wondering what might be the problem.
>
> Thanks,
>
> John Chien
>
> Following is my code:
> ************************************************************************************************
>    ArrayList list = null;
>    int skipCount = 0;
>    int maxCount = 500;
>    boolean done = false;
>    int facilityCount = 0;
>
>    while (! done) {
>         list = (ArrayList)
> getSqlMapClientTemplate().queryForList("getIIBillableFacilityList",
> formBean, skipCount, maxCount);
>         if ((list != null) && (list.size() > 0)) {
>             for (int i = 0; i < list.size(); i++) {
>                   FacilityNameAddressBean facility =
> (FacilityNameAddressBean) list.get(i);
>                   insertFirstBillingRecord(formBean, facility.getId(),
> userId);
>
>                   facilityCount++;
>                }
>                skipCount += list.size();
>
>                if (list.size() < maxCount) {
>                    done = true;
>                }
>            } else {
>                done = true;
>            }
>        }
> }
>
> **********************************************************************
> ******************************
>
>

Re: queryForList()

Posted by John Chien <jo...@ncmail.net>.
Christian:

1)  I look at the RowHandler interface.
Eventually, it will return the whole list. That means it will return a 
list of 10198 records.
That is exactly I tried to avoid. I do not want it to return me such a 
big list.

I know that the RowHandler itself will try to to the insertion for me.
However, I have no idea of how many insertion has been executed, unless 
I wait for it to return me such a big list.

2) How can I put the maxCount in the SQL statement ?
    Although the SQL statement will return me a list of objects, how can 
I put it in SQL statement to return me a range of objects while I do not 
have
    idea of how many objects will be returned.

Thanks,

John Chien

Poitras Christian wrote:
> It would be better if your code would do one of the following.
> 1) Use a RowHandler. This is optimized for these kind of queries.
> 2) Use maxCount in your SQL statement and not in queryForList. Some connectors don't use maximum count to limit the number of results sent from the database. In these cases limiting number of results in the SQL statement is your only choice.
>
> I would go with solution 1 unless you cannot use a RowHandler.
>
> Christian
>
>
> -----Original Message-----
> From: John Chien [mailto:john.chien@ncmail.net]
> Sent: Friday, October 17, 2008 11:02 AM
> To: user-java@ibatis.apache.org
> Subject: queryForList()
>
>
> Dear Sir:
>
> I used the SQLMAP' s API queryForList to get data back from database.
> There are many data in database, so I the one that has four input parameters.
> The SQLMAP XML syntax should return me 10198 records, if runs without loop.
> I have already tested this by plugin the values.
>
> However, I have it runs in loop and bring back 500 records every time.
> It should run 21 times. However, it returns null at the 12 loops (very consistently. I try many times) I am wondering what might be the problem.
>
> Thanks,
>
> John Chien
>
> Following is my code:
> ************************************************************************************************
>    ArrayList list = null;
>    int skipCount = 0;
>    int maxCount = 500;
>    boolean done = false;
>    int facilityCount = 0;
>
>    while (! done) {
>         list = (ArrayList)
> getSqlMapClientTemplate().queryForList("getIIBillableFacilityList",
> formBean, skipCount, maxCount);
>         if ((list != null) && (list.size() > 0)) {
>             for (int i = 0; i < list.size(); i++) {
>                   FacilityNameAddressBean facility =
> (FacilityNameAddressBean) list.get(i);
>                   insertFirstBillingRecord(formBean, facility.getId(), userId);
>
>                   facilityCount++;
>                }
>                skipCount += list.size();
>
>                if (list.size() < maxCount) {
>                    done = true;
>                }
>            } else {
>                done = true;
>            }
>        }
> }
>
> ****************************************************************************************************
>
>   

RE: queryForList()

Posted by Poitras Christian <Ch...@ircm.qc.ca>.
It would be better if your code would do one of the following.
1) Use a RowHandler. This is optimized for these kind of queries.
2) Use maxCount in your SQL statement and not in queryForList. Some connectors don't use maximum count to limit the number of results sent from the database. In these cases limiting number of results in the SQL statement is your only choice.

I would go with solution 1 unless you cannot use a RowHandler.

Christian


-----Original Message-----
From: John Chien [mailto:john.chien@ncmail.net]
Sent: Friday, October 17, 2008 11:02 AM
To: user-java@ibatis.apache.org
Subject: queryForList()


Dear Sir:

I used the SQLMAP' s API queryForList to get data back from database.
There are many data in database, so I the one that has four input parameters.
The SQLMAP XML syntax should return me 10198 records, if runs without loop.
I have already tested this by plugin the values.

However, I have it runs in loop and bring back 500 records every time.
It should run 21 times. However, it returns null at the 12 loops (very consistently. I try many times) I am wondering what might be the problem.

Thanks,

John Chien

Following is my code:
************************************************************************************************
   ArrayList list = null;
   int skipCount = 0;
   int maxCount = 500;
   boolean done = false;
   int facilityCount = 0;

   while (! done) {
        list = (ArrayList)
getSqlMapClientTemplate().queryForList("getIIBillableFacilityList",
formBean, skipCount, maxCount);
        if ((list != null) && (list.size() > 0)) {
            for (int i = 0; i < list.size(); i++) {
                  FacilityNameAddressBean facility =
(FacilityNameAddressBean) list.get(i);
                  insertFirstBillingRecord(formBean, facility.getId(), userId);

                  facilityCount++;
               }
               skipCount += list.size();

               if (list.size() < maxCount) {
                   done = true;
               }
           } else {
               done = true;
           }
       }
}

****************************************************************************************************


queryForList()

Posted by John Chien <jo...@ncmail.net>.
Dear Sir:

I used the SQLMAP' s API queryForList to get data back from database.
There are many data in database, so I the one that has four input 
parameters.
The SQLMAP XML syntax should return me 10198 records, if runs without loop.
I have already tested this by plugin the values.

However, I have it runs in loop and bring back 500 records every time.
It should run 21 times. However, it returns null at the 12 loops (very 
consistently. I try many times)
I am wondering what might be the problem.

Thanks,

John Chien

Following is my code:
************************************************************************************************
   ArrayList list = null;
   int skipCount = 0;
   int maxCount = 500;
   boolean done = false;
   int facilityCount = 0;
      
   while (! done) {
        list = (ArrayList) 
getSqlMapClientTemplate().queryForList("getIIBillableFacilityList", 
formBean, skipCount, maxCount);
        if ((list != null) && (list.size() > 0)) {
            for (int i = 0; i < list.size(); i++) {
                  FacilityNameAddressBean facility = 
(FacilityNameAddressBean) list.get(i);
                  insertFirstBillingRecord(formBean, facility.getId(), 
userId);
                 
                  facilityCount++;
               }
               skipCount += list.size();
              
               if (list.size() < maxCount) {
                   done = true;
               }
           } else {
               done = true;
           }
       }
}

****************************************************************************************************


Re: 2.3.4.726 and XmlConverter

Posted by Clinton Begin <cl...@gmail.com>.
I don't think Zsolt is talking about the XML results/parameters support in
iBATIS.  XMLConverter was a class used to literally translate iBATIS 1.x
mapping files into iBATIS 2.x mapping files using XSLT. It allowed either
runtime conversion or batch conversion.

Zsolt could use the old version to do the one-time conversion of all of his
files if he wants, but it sounds like he is extending the class for some
reason, in which case he could just grab the code and make it his own.

Clinton

On Thu, Oct 16, 2008 at 5:02 PM, <Ch...@sybase.com> wrote:

>
> As a suggestion Zsolt, iBatis does OR mapping extremely well. What you are
> looking for is something that will map Objects into XML extremely well. Why
> not take a look at XStream by thoughtworks. I'm using their library for
> several projects pertaining to Object -> XML and it handles them
> exceptionally well. And by utilizing a library like this it will give you a
> clean separation of concern as well as better control over the XML that you
> want to generate.
>
> http://xstream.codehaus.org/
>
>
>
>   *"Clinton Begin" <cl...@gmail.com>*
>
> 10/16/2008 03:42 PM   Please respond to
> user-java@ibatis.apache.org
>
>    To
>  user-java@ibatis.apache.org
>  cc
>   Subject
> Re: 2.3.4.726 and XmlConverter
>
>
>
>
>
> Zsolt,
>
> This feature is really old and was only there to support 1.x clients during
> the transition to 2.x.  If you're still have 1.x maps, it might be a good
> time to move them.  Otherwise, consider it a deprecated feature.  Thus, the
> long-term solution is for you to either adopt the code as your own, or
> migrate your SQL mapping files.
>
> cheers
> Clinton
>
> On Thu, Oct 16, 2008 at 2:56 PM, Zsolt Koppany <*z...@intland.com>>
> wrote:
> Larry,
>
> are there better options that will work long term?
>
> What is the recommended way today?
>
> Zsolt
>
> > -----Original Message-----
> > From: Larry Meadors [mailto:*larry.meadors@gmail.com*<la...@gmail.com>
> ]
> > Sent: Thursday, October 16, 2008 3:55 PM
> > To: *user-java@ibatis.apache.org* <us...@ibatis.apache.org>
> > Subject: Re: 2.3.4.726 and XmlConverter
> >
> > Two options:
> >
> >  - stick with the older version of ibatis that has all the parts you need
> >  - extract the parts you need from the older version of ibatis and use
> > them alongside the new release
> >
> > Larry
>
>
>

Re: 2.3.4.726 and XmlConverter

Posted by Ch...@sybase.com.
As a suggestion Zsolt, iBatis does OR mapping extremely well. What you are 
looking for is something that will map Objects into XML extremely well. 
Why not take a look at XStream by thoughtworks. I'm using their library 
for several projects pertaining to Object -> XML and it handles them 
exceptionally well. And by utilizing a library like this it will give you 
a clean separation of concern as well as better control over the XML that 
you want to generate.

http://xstream.codehaus.org/




"Clinton Begin" <cl...@gmail.com> 
10/16/2008 03:42 PM
Please respond to
user-java@ibatis.apache.org


To
user-java@ibatis.apache.org
cc

Subject
Re: 2.3.4.726 and XmlConverter






Zsolt, 

This feature is really old and was only there to support 1.x clients 
during the transition to 2.x.  If you're still have 1.x maps, it might be 
a good time to move them.  Otherwise, consider it a deprecated feature. 
Thus, the long-term solution is for you to either adopt the code as your 
own, or migrate your SQL mapping files. 

cheers
Clinton

On Thu, Oct 16, 2008 at 2:56 PM, Zsolt Koppany <zk...@intland.com> 
wrote:
Larry,

are there better options that will work long term?

What is the recommended way today?

Zsolt

> -----Original Message-----
> From: Larry Meadors [mailto:larry.meadors@gmail.com]
> Sent: Thursday, October 16, 2008 3:55 PM
> To: user-java@ibatis.apache.org
> Subject: Re: 2.3.4.726 and XmlConverter
>
> Two options:
>
>  - stick with the older version of ibatis that has all the parts you 
need
>  - extract the parts you need from the older version of ibatis and use
> them alongside the new release
>
> Larry



Re: 2.3.4.726 and XmlConverter

Posted by Clinton Begin <cl...@gmail.com>.
Zsolt,

This feature is really old and was only there to support 1.x clients during
the transition to 2.x.  If you're still have 1.x maps, it might be a good
time to move them.  Otherwise, consider it a deprecated feature.  Thus, the
long-term solution is for you to either adopt the code as your own, or
migrate your SQL mapping files.

cheers
Clinton

On Thu, Oct 16, 2008 at 2:56 PM, Zsolt Koppany <zk...@intland.com>wrote:

> Larry,
>
> are there better options that will work long term?
>
> What is the recommended way today?
>
> Zsolt
>
> > -----Original Message-----
> > From: Larry Meadors [mailto:larry.meadors@gmail.com]
> > Sent: Thursday, October 16, 2008 3:55 PM
> > To: user-java@ibatis.apache.org
> > Subject: Re: 2.3.4.726 and XmlConverter
> >
> > Two options:
> >
> >  - stick with the older version of ibatis that has all the parts you need
> >  - extract the parts you need from the older version of ibatis and use
> > them alongside the new release
> >
> > Larry
>
>

Re: 2.3.4.726 and XmlConverter

Posted by Clinton Begin <cl...@gmail.com>.
I believe those converters were pretty isolated.  So it would hopefully be
easy to extract them and run them in their own JAR or as part of your own
source code.

Clinton

On Thu, Oct 16, 2008 at 7:54 AM, Larry Meadors <la...@gmail.com>wrote:

> Two options:
>
>  - stick with the older version of ibatis that has all the parts you need
>  - extract the parts you need from the older version of ibatis and use
> them alongside the new release
>
> Larry
>

RE: 2.3.4.726 and XmlConverter

Posted by Zsolt Koppany <zk...@intland.com>.
Larry,

are there better options that will work long term?

What is the recommended way today?

Zsolt 

> -----Original Message-----
> From: Larry Meadors [mailto:larry.meadors@gmail.com]
> Sent: Thursday, October 16, 2008 3:55 PM
> To: user-java@ibatis.apache.org
> Subject: Re: 2.3.4.726 and XmlConverter
> 
> Two options:
> 
>  - stick with the older version of ibatis that has all the parts you need
>  - extract the parts you need from the older version of ibatis and use
> them alongside the new release
> 
> Larry


Re: 2.3.4.726 and XmlConverter

Posted by Larry Meadors <la...@gmail.com>.
Two options:

 - stick with the older version of ibatis that has all the parts you need
 - extract the parts you need from the older version of ibatis and use
them alongside the new release

Larry

RE: 2.3.4.726 and XmlConverter

Posted by Zsolt Koppany <zk...@intland.com>.
Kai ,

we tried to upgrade from 2.3.0.677 to 2.3.4.726.

http://ibatis.apache.org/javadownloads.cgi

http://apache.linux-mirror.org/ibatis/binaries/ibatis.java/ibatis-2.3.4.726.
zip

We have to pre-process the SQL statements thus this problem is a
show-stopper for us.

Zsolt 
> -----Original Message-----
> From: Kai Grabfelder [mailto:nospam@kinokai.de]
> Sent: Wednesday, October 15, 2008 10:29 PM
> To: user-java@ibatis.apache.org
> Subject: Re: 2.3.4.726 and XmlConverter
> 
> Hi Zsolt,
> 
> which version are you using now? It seem that this stuff was removed with
> revision 511363 (can be found in the
> subversion history):
> 
> Revision: 511363
> Author: cbegin
> Date: 00:40:42, Sonntag, 25. Februar 2007
> Message:
> Relatively minor refactorings.
> 1) Deleted BaseParser - moved Variables and utility methods to ParserState
> 2) Moved type alias mappings from SqlMapConfigParser to ParserState.
> 3) Deleted all XML Conversion related classes, methods and constructors
> (unsupported)
> 4) Noticed one possible bug, SqlStatementParser was using cache model
> properties instead of the global
> properties, so ${this} may not have been working...
> 5) Renamed properties and other variables in ParserState to hopefully be
> more clear.
> ----
> Deleted :
> /ibatis/trunk/java/mapper/mapper2/src/com/ibatis/sqlmap/engine/builder/xml
> /BaseParser.java
> Added :
> /ibatis/trunk/java/mapper/mapper2/src/com/ibatis/sqlmap/engine/builder/xml
> /ParserState.java
> Modified :
> /ibatis/trunk/java/mapper/mapper2/src/com/ibatis/sqlmap/engine/builder/xml
> /SqlMapConfigParser.java
> Modified :
> /ibatis/trunk/java/mapper/mapper2/src/com/ibatis/sqlmap/engine/builder/xml
> /SqlMapParser.java
> Modified :
> /ibatis/trunk/java/mapper/mapper2/src/com/ibatis/sqlmap/engine/builder/xml
> /SqlStatementParser.java
> Deleted :
> /ibatis/trunk/java/mapper/mapper2/src/com/ibatis/sqlmap/engine/builder/xml
> /XmlConverter.java
> 
> What are you doing with the XmlConverter?
> 
> Regards
> 
> Kai
> 
> 
> --- Original Nachricht ---
> Absender: Zsolt Koppany
> Datum: 14.10.2008 11:34
> > Hi,
> >
> > XmlConverter doesn't seem to be available in 2.3.4.726.
> >
> > We extend that class to pre-process xml files.
> >
> > What should we use instead of XmlConverter?
> >
> > Zsolt
> >
> >
> >


Re: 2.3.4.726 and XmlConverter

Posted by Kai Grabfelder <no...@kinokai.de>.
Hi Zsolt,

which version are you using now? It seem that this stuff was removed with revision 511363 (can be found in the
subversion history):

Revision: 511363
Author: cbegin
Date: 00:40:42, Sonntag, 25. Februar 2007
Message:
Relatively minor refactorings.
1) Deleted BaseParser - moved Variables and utility methods to ParserState
2) Moved type alias mappings from SqlMapConfigParser to ParserState.
3) Deleted all XML Conversion related classes, methods and constructors (unsupported)
4) Noticed one possible bug, SqlStatementParser was using cache model properties instead of the global
properties, so ${this} may not have been working...
5) Renamed properties and other variables in ParserState to hopefully be more clear.
----
Deleted : /ibatis/trunk/java/mapper/mapper2/src/com/ibatis/sqlmap/engine/builder/xml/BaseParser.java
Added : /ibatis/trunk/java/mapper/mapper2/src/com/ibatis/sqlmap/engine/builder/xml/ParserState.java
Modified : /ibatis/trunk/java/mapper/mapper2/src/com/ibatis/sqlmap/engine/builder/xml/SqlMapConfigParser.java
Modified : /ibatis/trunk/java/mapper/mapper2/src/com/ibatis/sqlmap/engine/builder/xml/SqlMapParser.java
Modified : /ibatis/trunk/java/mapper/mapper2/src/com/ibatis/sqlmap/engine/builder/xml/SqlStatementParser.java
Deleted : /ibatis/trunk/java/mapper/mapper2/src/com/ibatis/sqlmap/engine/builder/xml/XmlConverter.java

What are you doing with the XmlConverter?

Regards

Kai


--- Original Nachricht ---
Absender: Zsolt Koppany
Datum: 14.10.2008 11:34
> Hi,
> 
> XmlConverter doesn't seem to be available in 2.3.4.726.
> 
> We extend that class to pre-process xml files.
> 
> What should we use instead of XmlConverter?
> 
> Zsolt
> 
> 
>