Home › Forums › Jspresso core project › Jspresso users

many collection modules - same 'Content' area

Wed, 10/22/2008 - 23:50 — atao

I put many 'abstractFilterableBeanCollectionModule' under the same workplace without 'projectedViewDescriptor' attribute. Then the 'Content' area of each of them shows  the record list of the last one specified in the module list.
To get the record list  of the specified component, I had to put a 'projectedViewDescriptor' attribute for all the collection modules but the last one.
Is it the expected behavior?

‹ i18n Jspresso in 10 minutes ›
Sat, 10/25/2008 - 18:57 — vvandens

many collection modules - same 'Content' area

Hi,
There is actually a problem when defining 2 modules with the same name in the same workspace (which is somehow quite uncommon). For instance, take the HR sample application, duplicate the employees.module in the employees.workspace and change the name of your duplicated module to "employees2.module". Restart the application and you should have 2 independent filterable bean collection modules running on the same entity.
The problem you experience comes from the fact that 2 bean collection modules are considered equal if their names are equal. So for 2 modules with the same name, changes are not correctly reported. We might only rely on java object identity so that 2 different modules with the exact same description can co-exist in the application. I will file a bug on this and it should be fixed in the next maintenance release.
Can you confirm that this is what you did ? If not, you can post your workspace spring definition so that we can investigate further.
Best regards and thank you for test-driving Jspresso.
Vincent

Mon, 10/27/2008 - 01:32 — atao

Can you confirm that this is

Can you confirm that this is what you did ?
In fact the 2 bean collection modules don't have the same name et don't use the same entity:
    <property name="modules">      <list>               <bean parent="abstractFilterableBeanCollectionModule">                 <property name="name" value="masterdata.geography.cities.module" />                 <property name="description" value="masterdata.geography.cities.module.description" />                 <property name="elementComponentDescriptor" ref="City" />               </bean>               <bean parent="abstractFilterableBeanCollectionModule">                 <property name="name" value="masterdata.geography.countries.module" />                 <property name="description" value="masterdata.geography.countries.module.description" />                 <property name="elementComponentDescriptor" ref="Country" />               </bean>       </list>     </property>
As soon as I add in the first module:
           <property name="projectedViewDescriptor"    ref="city.table" />
everthing runs fine.
thank you for test-driving Jspresso
 
Jspresso is a great job!

Mon, 10/27/2008 - 20:22 — vvandens

You are absolutely right!

You are absolutely right! There is a bug regarding the abstractFilterableBeanCollectionModule and more precisely its generic projectedViewDescriptor reference. The latest points to filterableBeanCollectionModuleView that is declared with default 'singleton' Spring scope which means that a single instance of the view descriptor is shared for the whole Spring context.
 
When the front-end controller builds the workspace view, it goes through all the workspace modules and configures their projected views depending on their managed entities. So having multiple abstractFilterableBeanCollectionModule in the same workspace makes the last one "win" for configuring the shared table view (thus making all the others wrong...). The former process takes place workspace per workspace on-demand. That's why the bug does not appear when using a single filterableBeanCollectionModuleView in different workspaces. The workaround you submitted (which breaks the single projected view instance sharing) is actually the way to go until we fix the framework.
 
The fix is rather simple : we must declare filterableBeanCollectionModuleView with a 'prototype' Spring scope so that each time an instance is injected, it is a brand new instance.
BTW, the same problem exists on abstractBeanCollectionModule and its generic projected view beanCollectionModuleView (that must also have the 'prototype' scope).
I will take care of opening an issue in the tracker for this one and of course, it will be included in the next maintenance build.
 
Thanks a lot for having reported this.
Best regards,
Vincent