That does not work. In fact I'm not even sure that a transaction has
been initiated
I have made the following modification
1) DAO
<bean id="incidentDAO"
class="org.apache.camel.example.reportincident.dao.impl.IncidentDAOImpl">
<!-- <tx:transaction method="*" value="Required" /> -->
<jpa:context property="entityManager" unitname="ReportIncident" />
</bean>
2) Service
<bean id="incidentService"
class="org.apache.camel.example.reportincident.service.impl.IncidentServiceImpl">
<tx:transaction method="*" value="Required" />
<property name="incidentDAO">
<reference
interface="org.apache.camel.example.reportincident.dao.IncidentDAO"/>
</property>
</bean>
3) Simulation of an error
public class IncidentServiceImpl implements IncidentService {
private static final transient Log LOG =
LogFactory.getLog(IncidentServiceImpl.class);
/** The incident dao. */
private IncidentDAO incidentDAO;
public void saveIncident(Incident incident) {
try {
getIncidentDAO().saveIncident(incident);
throw new Exception(">> Generate Error to simulate RollBack");
} catch (RuntimeException e) {
e.printStackTrace();
} catch (Exception ex) {
ex.printStackTrace();
}
}
Is there a way to trace in log the Aries Transaction ?
Regards,
Charles
On 16/11/10 10:49, Valentin Mahrwald wrote:
On 16 Nov 2010, at 09:42, Charles Moulliard wrote:
There was a conflict with another ServiceMix bundle providing too jndi context.
I have remove it and restart my project. Everything works fine.
This is easier to configure compare to Spring + Hibernate stuffs on OSGI. I
will produce a tutorial with camel + aries + jpa + transaction + wicket about
that and show How Aries JPA/Transaction simplifies our lives on OSGI platform.
Question : In all the examples (Blog, AriesTrader), the transaction is defined
in the DAO layer (= layer containing the entityManager). Could it be possible
that I define the tx within the Service layer (in charge to call the DAO) ?
Yes, for all I know that should work. The JPA and Transaction extensions are
entirely independent. The transaction extensions manages the transaction bound
to the current thread while the JPA extension manages EntityManagers (and
-Factories) that access
the transaction currently active on the thread.
Regards,
Charles
On 16/11/10 10:26, Alasdair Nottingham wrote:
That is very odd. Something has not worked because the stack trace shows the
InitialContextFactoryBuilder has not been registered.
Could there be a timing issue? Perhaps the jndi bundle starts after your test.
Certainly the jndi bundle has the highest id.
Alasdair Nottingham
On 16 Nov 2010, at 09:11, Charles Moulliard<[email protected]> wrote:
Yes. The Aries JNDI bundle is started
[ 178] [Active ] [ ] [ ] [ 60] Apache Aries JNDI Bundle
(0.2.0.incubating)
On 16/11/10 09:52, Alasdair Nottingham wrote:
Hi,
Have you deployed and started the jndi bundle?
Alasdair
On 16 Nov 2010, at 08:18, Charles Moulliard<[email protected]> wrote:
Hi,
Based on the Blog example of Aries, I have created a small project that I
deploy on Fuse ESB (=Apache ServiceMix 4). The project includes a DAO layer
(=JPA), Service layer, Camel route (where a bean calls my service layer).
The following error is reported :
Caused by: java.lang.RuntimeException: The DataSource
osgi:service/javax.sql.DataSource/(osgi.jndi.service.name=jdbc/reportincidentdb)
could not be used.
at
org.apache.aries.jpa.container.unit.impl.DelayedLookupDataSource.getDs(DelayedLookupDataSource.java:47)
at
org.apache.aries.jpa.container.unit.impl.DelayedLookupDataSource.getConnection(DelayedLookupDataSource.java:60)
at
org.apache.openjpa.lib.jdbc.DelegatingDataSource.getConnection(DelegatingDataSource.java:137)
at
org.apache.openjpa.lib.jdbc.DecoratingDataSource.getConnection(DecoratingDataSource.java:112)
at
org.apache.openjpa.jdbc.schema.DataSourceFactory.installDBDictionary(DataSourceFactory.java:239)
... 100 more
Caused by: javax.naming.NoInitialContextException: Need to specify class name
in environment or system property, or as an applet parameter, or in an
application resource file: java.naming.factory.initial
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:645)
at
javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:288)[:1.6.0_22]
at
javax.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:325)[:1.6.0_22]
at javax.naming.InitialContext.lookup(InitialContext.java:392)[:1.6.0_22]
at
org.apache.aries.jpa.container.unit.impl.DelayedLookupDataSource.getDs(DelayedLookupDataSource.java:43)
Here is the bundle that I deploy to use Aries
[ 7] [Active ] [Created ] [ ] [ 20] Apache Aries Blueprint
Bundle (0.2.0.incubating)
[ 49] [Active ] [ ] [ ] [ 60] Apache Aries Transaction
Manager (0.2.0.incubating)
[ 167] [Active ] [Created ] [ ] [ 60] Aries JPA Container
blueprint integration for Aries blueprint (0.2.0.incubating)
[ 170] [Active ] [Created ] [ ] [ 60] Apache Aries Transaction
Blueprint (0.2.0.incubating)
[ 171] [Active ] [ ] [ ] [ 60] Aries JPA Container
(0.2.0.incubating)
[ 172] [Active ] [ ] [ ] [ 60] Apache Aries Util
(0.2.0.incubating)
[ 175] [Active ] [ ] [ ] [ 60] Aries JPA Container
Managed Contexts (0.2.0.incubating)
[ 178] [Active ] [ ] [ ] [ 60] Apache Aries JNDI Bundle
(0.2.0.incubating)
[ 166] [Active ] [Created ] [ ] [ 60] Reportincident ::
Persistence JPA :: Aries (1.0.0.SNAPSHOT)
[ 176] [Active ] [Created ] [ ] [ 60] Reportincident :: Service
Bundle :: Aries (1.0.0.SNAPSHOT)
What is the reason ? Is there a bundle that I miss to deploy ?
Regards,
Charles M.
Apache Committer (Camel, Servicmix and Karaf)
