This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

THere is no more problem if you just need to make a translation between a number and an enum or something like that, but if you need some other class to collaborate with foo.bar.MyTypeHandler, maybe it would be better to inject a spring bean instead of just a reference to a class allowing this way to inject some other beans to use inside the type handler class.

Is there a supported way to do this when Ibatis is integrated with spring or do I have to resort to complex and not safely statically accesible ApplicationContextAware or things like that?

Is there a supported way to do this when Ibatis is integrated with spring

iBatis is not integrated with Spring, instead Spring encapsulate iBatis but still, iBatis don't know shit about Spring. Thus what you are asking for (injecting some other beans to use inside the type handler class) is certainly not possible AFAIK.

On the other hand, iBatis type handlers where designed for rudimentary or straightforward type conversion (usually to or from a string representation) and thus having the need for another (business) bean from a type handlers sounds like a warning to my hears.

If you really have complex operation involving other beans in your iBatis type handlers, then you'd probably better move that code into your DAO - which should itself be a spring managed bean, and thus Spring DI enabled - as a before/after sql insert/retrieval processing.

Hope that make sense,
ZartC.

Comment

You are right, type handlers shouldn't be used for complex things (i.e. when a bean is required) but consider a scenario where the dao should return a list of beans, and these beans are persisted in a table, but half of the data is in an xml, and maybe some other data required to fully populate the pojo is gathered through a web service. Of course it could be done in DAO classes but don't you think it is a cleaner approach to allow IBatis to manage all of this by its own?

By the way, now I understand that spring is encapsulting IBatis, and providing helper classes for it (as the template), but it maybe could be possible to modify the way spring loads Ibatis sqlMapConfig to allow spring inject beans for typeHandlers, maybe with a spring namespace in SqlMapConfig configuration...
What do you think?

Comment

You are right, type handlers shouldn't be used for complex things (i.e. when a bean is required) but consider a scenario where the dao should return a list of beans, and these beans are persisted in a table, but half of the data is in an xml, and maybe some other data required to fully populate the pojo is gathered through a web service. Of course it could be done in DAO classes but don't you think it is a cleaner approach to allow IBatis to manage all of this by its own?

If I understand you well, your are assembling objects in a list, where part of each object data come from the database while other parts are coming from XML source and/or WebService. In this case you'd better move that code even higher in you layer stack. In extenso, I would develop what is called a TransferObjectAssembler. A TransferObjectAssembler would firstly call your DAO to retrieve the list of -partial- objects from the database, then it would walk the list of partial objects and call XAO/WebServices to retrieve the remaining data from external sources and complete the partial object. Once all objects are complete, the TransferObjectAssembler can return the list.

Conceptually, a TransferObjectAssembler sits in between your Service layer classes and the DAO, XAO, Werservices layer. Your services know that when they need that data, with is complex to assemble, they must get it through the TransferObjectAssembler instead of calling a DAO directly.

By the way, now I understand that spring is encapsulting IBatis, and providing helper classes for it (as the template), but it maybe could be possible to modify the way spring loads Ibatis sqlMapConfig to allow spring inject beans for typeHandlers, maybe with a spring namespace in SqlMapConfig configuration...
What do you think?

If you adopt the design architecture discussed above, I think it is not necessary