Sabarish Sasidharan

You are providing the same application context file to both the loaders (plugin and contextloaderlistener). And thats why its being loaded twice.

A better and more correct approach would be to split the applicationContext.xml into 2 files say, applicationContext-web.xml and applicationContext-main.xml. All the delegating proxy definitions can go into the applicationContext-struts.xml file and all other business logic, facade beans etc can go into the applicationContext-main.xml. Provide the applicationContext-struts.xml to the plugin and the other xml to the ContextLoaderListener. And yes beans defined in applicationContext-struts.xml can ref to the beans defined in applicationContext-main.xml.

You can change either the flush mode or force a flush programmatically, if thats what is bothering you.

The Hibernate flush mode you are using does not commit everything immediately on a save()/update(). But when you trigger a find, such unflushed data is flushed out immediately before the find is issued on the DB.

Originally posted by Ilja Preuss:
billOfMaterials.forAllProductsDo(new Closure<Product>() { public void execute(Product product) { // list product product.forEachPartDo(new Closure<Part>() { public void execute(Part part) { // list part } }); } });

I don't think this will give good performance. We might end up firing a lot of queries... Wouldn't a simpler way would be to use a SQL join (has its own costs) and retrieve the data. Especially if the DB has to be accessed over the network.

As Ilja has put it, i think you guys will finally end up developing your own ORM. It may not be a Hibernate, but it might atleast be close to an iBATIS.

If you are running this within a transaction and a runtime exception occurs, then the transaction will be rolled back. Are you sure you are not swallowing the exception somewhere?

Yes it worked !

So basically for each array instance attribute we have to add a getter accepting a int and a setter accepting int cum array type. The following code should make things clear.

private String[] roleIds; ... public String getRoleIds(int i) { return roleIds[i]; } public void setRoleIds(int i, String roleId) { roleIds[i] = roleId; }

Found the answer here, hope it works

http://www-128.ibm.com/developerworks/forums/dw_thread.jsp?message=13753412&cat=7&thread=64877&treeDisplayType=threadmode1&forum=199#13753412

I have a service that accepts a request object that inturn contains an array of Strings. I generated the wsdl using java2wsdl provided in the base_51 runtime of RAD 6.0. From the WSDL i then generated client and server stubs, serialization classes using wsdl2java again from the same runtime bin. I did not tinker around with options, just used the defaults...

I invoke the web service with request containing array of 6 strings, but when the control reaches my service implementation, there is only one string in the array. Has anybody faced a similar scenario? What could be going wrong here?

So from client
CreateRequest req = new CreateRequest() req.setCodes(new String[] {"1", "2", "3"}); locator.getCreateService().create(req);

When the control reaches the service implementation i see that the length of codes string array is 1 instead of 3 at runtime.

What could i be doing wrong?

Originally posted by Chris Richardson:
Hello,

A good first step might be to use iBATIS to simplify your code and move the SQL into external files.

JDO and Hibernate are roughly equivalent in terms of learning curve...

Chris

I too second the choice of iBATIS. I have never used iBATIS but have used a custom framework that very much resembles that. I have been using Hibernate for around 2 yrs now. And i know there are many ways of getting lost when using Hibernate.

FactoryBean is different from BeanFactory. BeanFactory is the lightweight container reference that you can use to get to the beans in the container. But FactoryBean is a bean that does not return a reference to itself but to an object it instantiates at run time. So when you inject a factory bean into bean X, the bean X will have a reference to the class instantiated by the factory bean and not the factory bean itself.

What are you using at the web layer? If using struts, you can define an a general exception handler for dataaccessexception. And for specific cases of data access exception, you might want to catch them in the Action layer and render differently.

The clearest benefit of integration IMHO is that you can get to springified beans easily from the Action layer.

Each interceptor supports only one target when using TransactionProxyFactoryBean. You can check out BeanNameAutoProxyCreator to support multiple targets (thereby avoiding having to put in a 5 line xml fragment for each target)

it seems ur spring applicationContext file is spring-manual-test.xml... so if you can get the relevant sections from there and paste them here it would be convenient