Agreed :)
The third trace essentially says your transaction is starting. But there is no
matching trace to say it commited :(
In error cases though you will get another trace entry, so by the looks all
your transactions succeed ?!
On 16 Nov 2010, at 13:08, Charles Moulliard wrote:
> BTW, I have enable tracing mode for the class org.apache.aries.transaction
> but the trace does not report begin and commit or rollback
>
> 14:05:42,952 | DEBUG | tenerContainer-1 | TxComponentMetaDataHelperImpl |
> on.TxComponentMetaDataHelperImpl 185 | 271 -
> org.apache.aries.transaction.blueprint - 0.2.0.incubating | Getting the
> txAttribute for the component {0} and method {1}
> 14:05:42,952 | DEBUG | tenerContainer-1 | TxComponentMetaDataHelperImpl |
> on.TxComponentMetaDataHelperImpl 197 | 271 -
> org.apache.aries.transaction.blueprint - 0.2.0.incubating | Return the
> txAttribute {0} for the component and method
> 14:05:42,953 | DEBUG | tenerContainer-1 | TxInterceptorImpl |
> es.transaction.TxInterceptorImpl 110 | 271 -
> org.apache.aries.transaction.blueprint - 0.2.0.incubating | Method: public
> void
> org.apache.camel.example.reportincident.dao.impl.IncidentDAOImpl.saveIncident(org.apache.camel.example.reportincident.model.Incident),
> has transaction strategy: REQUIRED
> 1
>
> This should be nice to have this info because for the moment we have no idea
> if the transaction occurs or not.
>
> On 16/11/10 13:44, Charles Moulliard wrote:
>> You are right. I made a mistake in my code to simulate an error + rollback
>>
>> On 16/11/10 12:21, Valentin Mahrwald wrote:
>>> I am a bit confused by the scenario. If I understand this correctly the
>>> saveIncident method throws an exception and catches it inside the method
>>> itself. So the transaction that spans around the saveIncident method would
>>> be unaffected ?!
>>>
>>> What are you trying to simulate?
>>>
>>> Just looking over it there is not a lot of trace. However,
>>> org.apache.aries.transaction.TxInterceptorImpl logs (at debug) when
>>> transactions start and if they fail.
>>>
>>> On 16 Nov 2010, at 10:37, Charles Moulliard wrote:
>>>
>>>> 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)
