Sounds like a valid problem. Can you open a jira issue for it?
Do you also observe this problem when using the new transaction
blueprint 2.0.0 using annotations?
Christian
Am 19.11.2015 um 16:04 schrieb mhshams:
Sorry for the very late reply. I just got some time to debug the code and I
think I found the issue.
The issue is reproducible by nesting the bean definition inside service
definition in blueprint xml.
<service interface="com.foo.MyDao">
<bean class="com.foo.impl.MyDaoImpl">
<tx:transaction method="*" value="Required"/>
</bean>
</service>
As a workaround I can change the above definition to following:
<bean id="myBean" class="com.foo.impl.MyDaoImpl">
<tx:transaction method="*" value="Required"/>
</bean>
<service interface="com.foo.MyDao">
<ref component-id="myBean" />
</service>
The root cause (probably a bug) is the process method in
"JpaComponentProcessor" class in aries jpa blueprint:
Set<String> components = new
HashSet<String>(cdr.getComponentDefinitionNames());
for (String component : components) {
ComponentMetadata compDef = cdr.getComponentDefinition(component);
if (compDef instanceof MutableBeanMetadata &&
!((MutableBeanMetadata)compDef).isProcessor()) {
handleComponent((MutableBeanMetadata)compDef, bundle, cdr,
container);
}
}
Above code is checking if component definition is an instance of
"MutableBeanMetadata" which is not the case when the bean definition is
nested in service definition. instead it is an instance of
"MutableServiceMetadata"
Cheers,
Mohammad Shamsi
--
View this message in context:
http://karaf.922171.n3.nabble.com/Problem-with-JPA-2-2-0-in-Karaf-4-0-2-tp4043078p4043623.html
Sent from the Karaf - User mailing list archive at Nabble.com.
