Re: Aries eclipselink.adapter
Good on you, Christian. Did you also run a transaction test? I mean with one faulty statement that should cause all the other participating transactions rollback? Alas, my problem appears to be in the support (rather lack of this) from MsSql or jtds driver. Frankly speaking I find this practice of manually creating the list for org.osgi.framework.system.packages is a doubtful practice. May be there is some option in eclipse/equinox to create it, but I didn't find it. I still use the generated config.ini. My class loader error I resolved by excluding javax.transaction bundle from the runtime (it was contained in the eclipse's plugins) Regards, Anatoly On 22/10/2012 6:07 PM, Christian Eugster wrote: Hi Anatoly, Today I succeeded lastly to save an entity in my testenvironment with following configuration: I did not use the ...(xa=true)) in the persistence.xml file. I startet my test environment that failed to save an entity. Then I copied the generated config.ini file in another (save from beeing deleted) place. In that file I copied the whole section of org.osgi.framework.system.packages=... (javax.transaction.. including) from the file proposed by Tim. Then I changed the run configuration of my test environment (section Configuration) by defining Use an existing config.ini file as a template pointing to the changed config.ini file (see above). Running this configuration did it. Regards Christian Am 20.10.12 13:31, schrieb Anatoly Osiko: Shame on me, of course, it's LDAP. I'll correct it. Alas, the easiest option 2) didn't work - I sent a separate message on that. Thank you. Regards, Anatoly. On 20/10/2012 9:54 PM, Timothy Ward wrote: Hi The bit in brackets for the jndi name is an ldap filter (just like a service lookup). What you want is ((osgi.jndi.service.name=jpa/jtaStagingDb)(xa=true)) You don't need to add entry key=xa value=true / to your service export, that gets added by the transaction wrappers bundle when it re-exports your service (to let you know it's the wrapped one). I think the easiest setup for you is to use: jta-data-sourceosgi:service/javax.sql.XADataSource/(osgi.jndi.service.name=jpa/jtaStagingDb)/jta-data-source service id=xaDataSource ref=stagingXADataSource interface=javax.sql.XADataSource service-properties entry key=osgi.jndi.service.name value=jpa/jtaStagingDb / /service-properties /service Regards, Tim Date: Sat, 20 Oct 2012 21:29:53 +1030 From: a...@solveitsoftware.com To: user@aries.apache.org Subject: Re: Aries eclipselink.adapter While you are still on-line, may I ask you for some clarifications; persistence.xml: the following apparently doesn't work: jta-data-sourceosgi:service/javax.sql.DataSource/(osgi.jndi.service.name=jpa/jtaStagingDb xa=true)/jta-data-source datasource blueprint? : neither this service id=xaDataSource ref=stagingXADataSource interface=javax.sql.DataSource service-properties entry key=osgi.jndi.service.name value=jpa/jtaStagingDb / entry key=xa value=true / /service-properties /service What's the correct syntax? On 20/10/2012 9:25 PM, Timothy Ward wrote: I'm glad I could help! I'll check with Manning about the discount code, I wasn't aware that it had an expiry date. Regards, Tim Date: Sat, 20 Oct 2012 21:08:05 +1030 From: a...@solveitsoftware.com mailto:a...@solveitsoftware.com To: user@aries.apache.org mailto:user@aries.apache.org Subject: Re: Aries eclipselink.adapter Hi, Timothy. Thank you, your message arrived very handy just when I am wasting my Saturday night (UTC +9.30) in another attempt to make JTA work. For a more than a couple of week I put it on the back burner, while doing other tasks. I will look at your suggestions and also will purchase the book - thanks for the generous offer. I had only green paper and the source code so far. So, I may want to ask for an autograph from the author :). My OSGi crash course is lasting couple of month by now, so I had only chance to digest (albeit still suffering heartburn :) ) OSGi in Action. Though I realized at rather early stage that I have to deal with OSGi enterprise as far as JPA/JTA container support concerned. Kind regards, Anatoly PS The coupon code you have entered has expired I received this message when applied the code. On 20/10/2012 8:25 PM, Timothy Ward wrote: Hi, I'm afraid I haven't had time to do a full review, but from the log I see that your datasource services are both being registered by blueprint using the DataSource interface. Unless you're enlisting the JTA datasource with transactions yourself then this looks like the source of the problem
Re: Aries eclipselink.adapter
Hi, Christian. Below is an example of my definitions in the repository bundle: bean id=eventLogDAOImpl scope=prototype class=com.solveit.integration.db.internal.dao.EventLogDAOImpl jpa:context property=entityManager unitname=integration.employee / /bean bean id=employeeSyncRecordDAOImpl scope=prototype class=com.solveit.integration.employee.internal.dao.EmployeeSyncRecordDAOImpl jpa:context property=entityManager unitname=integration.employee / /bean bean id=employeeSyncRecordServiceImpl class=com.solveit.integration.employee.internal.service.EmployeeSyncRecordServiceImpl tx:transaction method=update*, insert* value=Required / property name=employeeSyncRecordDAO ref=employeeSyncRecordDAOImpl / property name=eventLogDAO ref=eventLogDAOImpl / /bean service id=employeeSyncRecordService ref=employeeSyncRecordServiceImpl interface=com.solveit.integration.employee.service.EmployeeSyncRecordService /service .. . and the test bundle: reference id=employeeServiceForTest timeout=6 activation=eager interface=com.solveit.integration.employee.service.EmployeeSyncRecordService / bean id=employeeServiceTest1 init-method=updateEmployeesTxFailedTest class=com.solveit.integration.test.EmployeeSyncRecordServiceTxTest property name=employeeService ref=employeeServiceForTest / /bean The EmployeeSyncRecordService, actually, has a business method already that executes two separate insert operations, something like that: Tx1 : eventLogDAO.update() Tx2 : employeeSyncRecordDAO.update () (insert error in one of the sql statements there) If the Tx2 fails then Tx1 should rollback. Regards, anatoly On 22/10/2012 6:52 PM, Christian Eugster wrote: Hi Anatoly, no, but that will be the next duty. For the moment I am trying to understand blueprint (I am new to all theses enterprise OSGi features). I will inform you, if and how I did it. Regards Christian Am 22.10.12 10:16, schrieb Anatoly Osiko: Good on you, Christian. Did you also run a transaction test? I mean with one faulty statement that should cause all the other participating transactions rollback? Alas, my problem appears to be in the support (rather lack of this) from MsSql or jtds driver. Frankly speaking I find this practice of manually creating the list for org.osgi.framework.system.packages is a doubtful practice. May be there is some option in eclipse/equinox to create it, but I didn't find it. I still use the generated config.ini. My class loader error I resolved by excluding javax.transaction bundle from the runtime (it was contained in the eclipse's plugins) Regards, Anatoly On 22/10/2012 6:07 PM, Christian Eugster wrote: Hi Anatoly, Today I succeeded lastly to save an entity in my testenvironment with following configuration: I did not use the ...(xa=true)) in the persistence.xml file. I startet my test environment that failed to save an entity. Then I copied the generated config.ini file in another (save from beeing deleted) place. In that file I copied the whole section of org.osgi.framework.system.packages=... (javax.transaction.. including) from the file proposed by Tim. Then I changed the run configuration of my test environment (section Configuration) by defining Use an existing config.ini file as a template pointing to the changed config.ini file (see above). Running this configuration did it. Regards Christian Am 20.10.12 13:31, schrieb Anatoly Osiko: Shame on me, of course, it's LDAP. I'll correct it. Alas, the easiest option 2) didn't work - I sent a separate message on that. Thank you. Regards, Anatoly. On 20/10/2012 9:54 PM, Timothy Ward wrote: Hi The bit in brackets for the jndi name is an ldap filter (just like a service lookup). What you want is ((osgi.jndi.service.name=jpa/jtaStagingDb)(xa=true)) You don't need to add entry key=xa value=true / to your service export, that gets added by the transaction wrappers bundle when it re-exports your service (to let you know it's the wrapped one). I think the easiest setup for you is to use: jta-data-sourceosgi:service/javax.sql.XADataSource/(osgi.jndi.service.name=jpa/jtaStagingDb)/jta-data-source service id=xaDataSource ref=stagingXADataSource interface=javax.sql.XADataSource service-properties entry key=osgi.jndi.service.name value=jpa/jtaStagingDb / /service-properties /service Regards, Tim Date: Sat, 20 Oct 2012 21:29:53 +1030 From: a...@solveitsoftware.com To: user@aries.apache.org Subject: Re: Aries eclipselink.adapter While you are still on-line, may I ask you for some clarifications; persistence.xml: the following apparently doesn't work: jta-data-sourceosgi:service/javax.sql.DataSource/(osgi.jndi.service.name=jpa/jtaStagingDb xa=true)/jta-data-source datasource blueprint? : neither this service id=xaDataSource ref=stagingXADataSource
Re: Aries eclipselink.adapter
Hi, Timothy. Thanks again for your guidance. I fixed the reported loader violation error by removing javax.transaction (1.1.1.v201105210645) bundle from the runtime configuration: it's in eclipse's plugins/javax.transaction_1.1.1.v201105210645.jar Now I am looking at MsSql server XA support, and this may be the problem for the kind of server we use. I wonder if the distributed tx support is a prerequisite for the aries transaction container. We don't have distributed transactions - there is only one datasource. Can it work with just javax.sql.DataSource? BTW, I purchased the e version of the Enterprise OSGi in Action using Manning's current promotional code *o1942. *Regards, Anatoly * * On 20/10/2012 10:43 PM, Timothy Ward wrote: Hi, Have you set up your system packages to prevent people getting wired to the split package in the JDK? If you look at https://svn.apache.org/repos/asf/aries/trunk/samples/blog/blog-assembly/src/main/filtered-resources/configuration/config.ini You can see that the org.osgi.framework.system.packages property sets a mandatory partial=true parameter on javax.transaction and javax.transaction.xa Regards, Tim Date: Sat, 20 Oct 2012 21:37:05 +1030 From: a...@solveitsoftware.com To: user@aries.apache.org Subject: Re: Aries eclipselink.adapter I tried the option 2) - I recollect tried it some time before. And now it also doesn't work - problem with MsSql driver Caused by: java.lang.LinkageError: loader constraint violation in interface itable initialization: when resolving method net.sourceforge.jtds.jdbcx.JtdsXAConnection.getXAResource()Ljavax/transaction/xa/XAResource; the class loader (instance of org/eclipse/osgi/internal/baseadaptor/DefaultClassLoader) of the current class, net/sourceforge/jtds/jdbcx/JtdsXAConnection, and the class loader (instance of bootloader) for interface javax/sql/XAConnection have different Class objects for the type javax/transaction/xa/XAResource used in the signature at net.sourceforge.jtds.jdbcx.JtdsDataSource.getXAConnection(JtdsDataSource.java:116) at org.apache.aries.transaction.jdbc.XADatasourceEnlistingWrapper.getConnection(XADatasourceEnlistingWrapper.java:63) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) So, the ball on the MsSql driver side? The bad news is that I am not aware of any other driver, and that one worked perfectly well with Spring framework JTA declarative support in non-OSGi environment. What do you think? On 20/10/2012 9:25 PM, Timothy Ward wrote: I'm glad I could help! I'll check with Manning about the discount code, I wasn't aware that it had an expiry date. Regards, Tim Date: Sat, 20 Oct 2012 21:08:05 +1030 From: a...@solveitsoftware.com mailto:a...@solveitsoftware.com To: user@aries.apache.org mailto:user@aries.apache.org Subject: Re: Aries eclipselink.adapter Hi, Timothy. Thank you, your message arrived very handy just when I am wasting my Saturday night (UTC +9.30) in another attempt to make JTA work. For a more than a couple of week I put it on the back burner, while doing other tasks. I will look at your suggestions and also will purchase the book - thanks for the generous offer. I had only green paper and the source code so far. So, I may want to ask for an autograph from the author :). My OSGi crash course is lasting couple of month by now, so I had only chance to digest (albeit still suffering heartburn :) ) OSGi in Action. Though I realized at rather early stage that I have to deal with OSGi enterprise as far as JPA/JTA container support concerned. Kind regards, Anatoly PS The coupon code you have entered has expired I received this message when applied the code. On 20/10/2012 8:25 PM, Timothy Ward wrote: Hi, I'm afraid I haven't had time to do a full review, but from the log I see that your datasource services are both being registered by blueprint using the DataSource interface. Unless you're enlisting the JTA datasource with transactions yourself then this looks like the source of the problem. If you want the Aries runtime to do the enlistment then you need to register the datasource as an XADataSource. There are then two options: 1. You can let the transaction wrappers bundle do the enlistment and add (xa=true) to your JTA-data-source jndi name 2. You can let the JPA container do the enlistment by changing the JTA-data-source jndi name to use XADataSource as the interface. This will only work for Aries JPA 1.0 and higher. If you are after more information about setting up OSGi applications with JPA then there's a whole chapter about
Re: Aries eclipselink.adapter
While you are still on-line, may I ask you for some clarifications; persistence.xml: the following apparently doesn't work: jta-data-sourceosgi:service/javax.sql.DataSource/(osgi.jndi.service.name=jpa/jtaStagingDb xa=true)/jta-data-source datasource blueprint? : neither this service id=xaDataSource ref=stagingXADataSource interface=javax.sql.DataSource service-properties entry key=osgi.jndi.service.name value=jpa/jtaStagingDb / entry key=xa value=true / /service-properties /service What's the correct syntax? On 20/10/2012 9:25 PM, Timothy Ward wrote: I'm glad I could help! I'll check with Manning about the discount code, I wasn't aware that it had an expiry date. Regards, Tim Date: Sat, 20 Oct 2012 21:08:05 +1030 From: a...@solveitsoftware.com To: user@aries.apache.org Subject: Re: Aries eclipselink.adapter Hi, Timothy. Thank you, your message arrived very handy just when I am wasting my Saturday night (UTC +9.30) in another attempt to make JTA work. For a more than a couple of week I put it on the back burner, while doing other tasks. I will look at your suggestions and also will purchase the book - thanks for the generous offer. I had only green paper and the source code so far. So, I may want to ask for an autograph from the author :). My OSGi crash course is lasting couple of month by now, so I had only chance to digest (albeit still suffering heartburn :) ) OSGi in Action. Though I realized at rather early stage that I have to deal with OSGi enterprise as far as JPA/JTA container support concerned. Kind regards, Anatoly PS The coupon code you have entered has expired I received this message when applied the code. On 20/10/2012 8:25 PM, Timothy Ward wrote: Hi, I'm afraid I haven't had time to do a full review, but from the log I see that your datasource services are both being registered by blueprint using the DataSource interface. Unless you're enlisting the JTA datasource with transactions yourself then this looks like the source of the problem. If you want the Aries runtime to do the enlistment then you need to register the datasource as an XADataSource. There are then two options: 1. You can let the transaction wrappers bundle do the enlistment and add (xa=true) to your JTA-data-source jndi name 2. You can let the JPA container do the enlistment by changing the JTA-data-source jndi name to use XADataSource as the interface. This will only work for Aries JPA 1.0 and higher. If you are after more information about setting up OSGi applications with JPA then there's a whole chapter about it in Enterprise OSGi in Action, along with chapters about tools, testing, web applications and remoting. You can get it at http://www.manning.com/cummins and get 37% off using the code eosgi37. I hope this helps you get set up ok. Regards, Tim Date: Mon, 15 Oct 2012 01:55:59 +1030 From: a...@solveitsoftware.com mailto:a...@solveitsoftware.com To: user@aries.apache.org mailto:user@aries.apache.org Subject: Re: Aries eclipselink.adapter Thank you, Timothy. I use the current release 1.0.0 of aries http://aries.apache.org/downloads/currentrelease.html I have attached the blueprint context files - blueprint seems to be the only way at the moment to use declarative, AOP style, transactions support. And the test class invoked in blueprint-test.xml blueprint-datasource.xml -- blueprint context of the database bundle blueprint-employee.xml - blueprint of employee bundle blueprint-test - blueprint of the integration test routines bundle persistence-jta.xml - the JPA/JTA persistence unit configuration I must confess, that I don't know what is auto-enlisting datasource. Regards, Anatoly PS I also attached the log of the test with the deliberately induced sql error. The rollback is announced, but all the insert statements, except for the offending one, still get committed, including the cascade insertions. So, no actual rollback is performed. On 12/10/2012 9:40 PM, Timothy Ward wrote: Hi Anatoly, I'd be interested in seeing the configuration for the transactions that failed to roll back, and in knowing what version of Aries JPA you were using. If you don't give the JPA container an auto-enlisting datasource then you can end up with non-transactional behaviour. This is why we have the transaction-wrappers bundle. Tim Date: Fri, 12 Oct 2012 09:46:39 +1030 From: a...@solveitsoftware.com mailto:a...@solveitsoftware.com To: user@aries.apache.org mailto:user@aries.apache.org Subject: Re: Aries eclipselink.adapter
RE: Aries eclipselink.adapter
Hi The bit in brackets for the jndi name is an ldap filter (just like a service lookup). What you want is ((osgi.jndi.service.name=jpa/jtaStagingDb)(xa=true)) You don't need to add entry key=xa value=true / to your service export, that gets added by the transaction wrappers bundle when it re-exports your service (to let you know it's the wrapped one). I think the easiest setup for you is to use: jta-data-sourceosgi:service/javax.sql.XADataSource/(osgi.jndi.service.name=jpa/jtaStagingDb)/jta-data-source service id=xaDataSource ref=stagingXADataSource interface=javax.sql.XADataSource service-properties entry key=osgi.jndi.service.name value=jpa/jtaStagingDb / /service-properties /service Regards, Tim Date: Sat, 20 Oct 2012 21:29:53 +1030 From: a...@solveitsoftware.com To: user@aries.apache.org Subject: Re: Aries eclipselink.adapter While you are still on-line, may I ask you for some clarifications; persistence.xml: the following apparently doesn't work: jta-data-sourceosgi:service/javax.sql.DataSource/(osgi.jndi.service.name=jpa/jtaStagingDb xa=true)/jta-data-source datasource blueprint? : neither this service id=xaDataSource ref=stagingXADataSource interface=javax.sql.DataSource service-properties entry key=osgi.jndi.service.name value=jpa/jtaStagingDb / entry key=xa value=true / /service-properties /service What's the correct syntax? On 20/10/2012 9:25 PM, Timothy Ward wrote: I'm glad I could help! I'll check with Manning about the discount code, I wasn't aware that it had an expiry date. Regards, Tim Date: Sat, 20 Oct 2012 21:08:05 +1030 From: a...@solveitsoftware.com To: user@aries.apache.org Subject: Re: Aries eclipselink.adapter Hi, Timothy. Thank you, your message arrived very handy just when I am wasting my Saturday night (UTC +9.30) in another attempt to make JTA work. For a more than a couple of week I put it on the back burner, while doing other tasks. I will look at your suggestions and also will purchase the book - thanks for the generous offer. I had only green paper and the source code so far. So, I may want to ask for an autograph from the author :). My OSGi crash course is lasting couple of month by now, so I had only chance to digest (albeit still suffering heartburn :) ) OSGi in Action. Though I realized at rather early stage that I have to deal with OSGi enterprise as far as JPA/JTA container support concerned. Kind regards, Anatoly PS The coupon code you have entered has expired I received this message when applied the code. On 20/10/2012 8:25 PM, Timothy Ward wrote: Hi, I'm afraid I haven't had time to do a full review, but from the log I see that your datasource services are both being registered by blueprint using the DataSource interface. Unless you're enlisting the JTA datasource with transactions yourself then this looks like the source of the problem. If you want the Aries runtime to do the enlistment then you need to register the datasource as an XADataSource. There are then two options: 1. You can let the transaction wrappers bundle do the enlistment and add (xa=true) to your JTA-data-source jndi name 2. You can let the JPA container do the enlistment by changing the JTA-data-source jndi name to use XADataSource as the interface. This will only work for Aries JPA 1.0 and higher. If you are after more information about setting up OSGi applications with JPA then there's a whole chapter about it in Enterprise OSGi in Action, along with chapters about tools, testing, web applications and remoting. You can get it at http://www.manning.com/cummins and get 37% off using the code eosgi37. I hope this helps you get set up ok. Regards, Tim Date: Mon, 15 Oct 2012 01:55:59 +1030 From: a...@solveitsoftware.com To: user@aries.apache.org Subject: Re: Aries eclipselink.adapter Thank you, Timothy
Re: Aries eclipselink.adapter
... my progress so far : With this line in the persistence.xml jta-data-sourceosgi:service/javax.sql.DataSource/(amp;(osgi.jndi.service.name=jpa/jtaStagingDb)(xa=true))/jta-data-source Yet, the result is still as before: all the participating transactions apart from the offending one got commited. My only choice is to MsSql, and the problem might be with the driver. Of course, I might try to build the test case with other database to verify this. As for the latest suggestions to tweak the config.ini ... This one is generated (Eclipse default option: generate with default content) and doesn't bother to specify the org.osgi.framework.system.packages property. I definitely not going to create that listing manually - it's crazy. At this very moment I tend to point finger to MsSql ... Regards, Anatoly On 20/10/2012 10:43 PM, Timothy Ward wrote: Hi, Have you set up your system packages to prevent people getting wired to the split package in the JDK? If you look at https://svn.apache.org/repos/asf/aries/trunk/samples/blog/blog-assembly/src/main/filtered-resources/configuration/config.ini You can see that the org.osgi.framework.system.packages property sets a mandatory partial=true parameter on javax.transaction and javax.transaction.xa Regards, Tim Date: Sat, 20 Oct 2012 21:37:05 +1030 From: a...@solveitsoftware.com To: user@aries.apache.org Subject: Re: Aries eclipselink.adapter I tried the option 2) - I recollect tried it some time before. And now it also doesn't work - problem with MsSql driver Caused by: java.lang.LinkageError: loader constraint violation in interface itable initialization: when resolving method net.sourceforge.jtds.jdbcx.JtdsXAConnection.getXAResource()Ljavax/transaction/xa/XAResource; the class loader (instance of org/eclipse/osgi/internal/baseadaptor/DefaultClassLoader) of the current class, net/sourceforge/jtds/jdbcx/JtdsXAConnection, and the class loader (instance of bootloader) for interface javax/sql/XAConnection have different Class objects for the type javax/transaction/xa/XAResource used in the signature at net.sourceforge.jtds.jdbcx.JtdsDataSource.getXAConnection(JtdsDataSource.java:116) at org.apache.aries.transaction.jdbc.XADatasourceEnlistingWrapper.getConnection(XADatasourceEnlistingWrapper.java:63) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) So, the ball on the MsSql driver side? The bad news is that I am not aware of any other driver, and that one worked perfectly well with Spring framework JTA declarative support in non-OSGi environment. What do you think? On 20/10/2012 9:25 PM, Timothy Ward wrote: I'm glad I could help! I'll check with Manning about the discount code, I wasn't aware that it had an expiry date. Regards, Tim Date: Sat, 20 Oct 2012 21:08:05 +1030 From: a...@solveitsoftware.com mailto:a...@solveitsoftware.com To: user@aries.apache.org mailto:user@aries.apache.org Subject: Re: Aries eclipselink.adapter Hi, Timothy. Thank you, your message arrived very handy just when I am wasting my Saturday night (UTC +9.30) in another attempt to make JTA work. For a more than a couple of week I put it on the back burner, while doing other tasks. I will look at your suggestions and also will purchase the book - thanks for the generous offer. I had only green paper and the source code so far. So, I may want to ask for an autograph from the author :). My OSGi crash course is lasting couple of month by now, so I had only chance to digest (albeit still suffering heartburn :) ) OSGi in Action. Though I realized at rather early stage that I have to deal with OSGi enterprise as far as JPA/JTA container support concerned. Kind regards, Anatoly PS The coupon code you have entered has expired I received this message when applied the code. On 20/10/2012 8:25 PM, Timothy Ward wrote: Hi, I'm afraid I haven't had time to do a full review, but from the log I see that your datasource services are both being registered by blueprint using the DataSource interface. Unless you're enlisting the JTA datasource with transactions yourself then this looks like the source of the problem. If you want the Aries runtime to do the enlistment then you need to register the datasource as an XADataSource. There are then two options: 1. You can let the transaction wrappers bundle do the enlistment and add (xa=true) to your JTA-data-source jndi name 2. You can let the JPA container do the enlistment by changing the JTA-data-source jndi name to use XADataSource as the interface. This will only work for Aries JPA 1.0 and higher. If you
Re: Aries eclipselink.adapter
Yes. On 21/10/2012 12:48 AM, Timothy Ward wrote: This was in addition to changing your datasource blueprint to: service id=xaDataSource ref=stagingXADataSource interface=javax.sql.XADataSource service-properties entry key=osgi.jndi.service.name value=jpa/jtaStagingDb / /service-properties /service wasn't it? Tim Date: Sun, 21 Oct 2012 00:02:21 +1030 From: a...@solveitsoftware.com To: user@aries.apache.org Subject: Re: Aries eclipselink.adapter ... my progress so far : With this line in the persistence.xml jta-data-sourceosgi:service/javax.sql.DataSource/(amp;(osgi.jndi.service.name=jpa/jtaStagingDb)(xa=true))/jta-data-source Yet, the result is still as before: all the participating transactions apart from the offending one got commited. My only choice is to MsSql, and the problem might be with the driver. Of course, I might try to build the test case with other database to verify this. As for the latest suggestions to tweak the config.ini ... This one is generated (Eclipse default option: generate with default content) and doesn't bother to specify the org.osgi.framework.system.packages property. I definitely not going to create that listing manually - it's crazy. At this very moment I tend to point finger to MsSql ... Regards, Anatoly On 20/10/2012 10:43 PM, Timothy Ward wrote: Hi, Have you set up your system packages to prevent people getting wired to the split package in the JDK? If you look at https://svn.apache.org/repos/asf/aries/trunk/samples/blog/blog-assembly/src/main/filtered-resources/configuration/config.ini You can see that the org.osgi.framework.system.packages property sets a mandatory partial=true parameter on javax.transaction and javax.transaction.xa Regards, Tim Date: Sat, 20 Oct 2012 21:37:05 +1030 From: a...@solveitsoftware.com mailto:a...@solveitsoftware.com To: user@aries.apache.org mailto:user@aries.apache.org Subject: Re: Aries eclipselink.adapter I tried the option 2) - I recollect tried it some time before. And now it also doesn't work - problem with MsSql driver Caused by: java.lang.LinkageError: loader constraint violation in interface itable initialization: when resolving method net.sourceforge.jtds.jdbcx.JtdsXAConnection.getXAResource()Ljavax/transaction/xa/XAResource; the class loader (instance of org/eclipse/osgi/internal/baseadaptor/DefaultClassLoader) of the current class, net/sourceforge/jtds/jdbcx/JtdsXAConnection, and the class loader (instance of bootloader) for interface javax/sql/XAConnection have different Class objects for the type javax/transaction/xa/XAResource used in the signature at net.sourceforge.jtds.jdbcx.JtdsDataSource.getXAConnection(JtdsDataSource.java:116) at org.apache.aries.transaction.jdbc.XADatasourceEnlistingWrapper.getConnection(XADatasourceEnlistingWrapper.java:63) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) So, the ball on the MsSql driver side? The bad news is that I am not aware of any other driver, and that one worked perfectly well with Spring framework JTA declarative support in non-OSGi environment. What do you think? On 20/10/2012 9:25 PM, Timothy Ward wrote: I'm glad I could help! I'll check with Manning about the discount code, I wasn't aware that it had an expiry date. Regards, Tim Date: Sat, 20 Oct 2012 21:08:05 +1030 From: a...@solveitsoftware.com mailto:a...@solveitsoftware.com To: user@aries.apache.org mailto:user@aries.apache.org Subject: Re: Aries eclipselink.adapter Hi, Timothy. Thank you, your message arrived very handy just when I am wasting my Saturday night (UTC +9.30) in another attempt to make JTA work. For a more than a couple of week I put it on the back burner, while doing other tasks. I will look at your suggestions and also will purchase the book - thanks for the generous offer. I had only green paper and the source code so far. So, I may want to ask for an autograph from the author :). My OSGi crash course is lasting couple of month by now, so I had only chance to digest (albeit still suffering heartburn :) ) OSGi in Action. Though I realized at rather early stage that I have to deal with OSGi enterprise as far as JPA/JTA container support concerned. Kind regards, Anatoly PS The coupon code you have entered has expired I received this message when applied the code. On 20/10/2012 8:25 PM, Timothy Ward wrote
RE: Aries eclipselink.adapter
In which case it is starting to sound as though there might be a problem with the db driver. Have you tried it with derby or similar? Tim Date: Sun, 21 Oct 2012 00:49:14 +1030 From: a...@solveitsoftware.com To: user@aries.apache.org Subject: Re: Aries eclipselink.adapter Yes. On 21/10/2012 12:48 AM, Timothy Ward wrote: This was in addition to changing your datasource blueprint to: service id=xaDataSource ref=stagingXADataSource interface=javax.sql.XADataSource service-properties entry key=osgi.jndi.service.name value=jpa/jtaStagingDb / /service-properties /service wasn't it? Tim Date: Sun, 21 Oct 2012 00:02:21 +1030 From: a...@solveitsoftware.com To: user@aries.apache.org Subject: Re: Aries eclipselink.adapter ... my progress so far : With this line in the persistence.xml jta-data-sourceosgi:service/javax.sql.DataSource/(amp;(osgi.jndi.service.name=jpa/jtaStagingDb)(xa=true))/jta-data-source Yet, the result is still as before: all the participating transactions apart from the offending one got commited. My only choice is to MsSql, and the problem might be with the driver. Of course, I might try to build the test case with other database to verify this. As for the latest suggestions to tweak the config.ini ... This one is generated (Eclipse default option: generate with default content) and doesn't bother to specify the org.osgi.framework.system.packages property. I definitely not going to create that listing manually - it's crazy. At this very moment I tend to point finger to MsSql ... Regards, Anatoly On 20/10/2012 10:43 PM, Timothy Ward wrote: Hi, Have you set up your system packages to prevent people getting wired to the split package in the JDK? If you look at https://svn.apache.org/repos/asf/aries/trunk/samples/blog/blog-assembly/src/main/filtered-resources/configuration/config.ini You can see that the org.osgi.framework.system.packages property sets a mandatory partial=true parameter on javax.transaction and javax.transaction.xa Regards, Tim Date: Sat, 20 Oct 2012 21:37:05 +1030 From: a...@solveitsoftware.com To: user@aries.apache.org Subject: Re: Aries eclipselink.adapter I tried the option 2) - I recollect tried it some time before. And now it also doesn't work - problem with MsSql driver Caused by: java.lang.LinkageError: loader constraint violation in interface itable initialization: when resolving method net.sourceforge.jtds.jdbcx.JtdsXAConnection.getXAResource()Ljavax/transaction/xa/XAResource; the class loader (instance of org/eclipse/osgi/internal/baseadaptor/DefaultClassLoader) of the current class, net/sourceforge/jtds/jdbcx/JtdsXAConnection, and the class loader (instance of bootloader) for interface javax/sql/XAConnection have different Class objects for the type javax/transaction/xa/XAResource used in the signature at net.sourceforge.jtds.jdbcx.JtdsDataSource.getXAConnection(JtdsDataSource.java:116) at org.apache.aries.transaction.jdbc.XADatasourceEnlistingWrapper.getConnection(XADatasourceEnlistingWrapper.java:63) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) So, the ball on the MsSql driver side? The bad news is that I am not aware of any other driver, and that one worked perfectly well with Spring framework JTA declarative support in non-OSGi environment. What do you think? On 20/10/2012 9:25 PM, Timothy Ward wrote: I'm glad I could help! I'll check with Manning about the discount code, I wasn't aware that it had an expiry date. Regards, Tim Date: Sat, 20 Oct 2012 21:08:05 +1030 From
Re: Aries eclipselink.adapter
Looks like you have two '' chars at the end of the blueprint element. John Re: Aries eclipselink.adapter Hi, I managed this by changing the version range of aries.util in the pom. But now I have another problem. After packaging I tried to run an example in the osgi-container. I get a ComponentDefinitionException saying Unable to validate xml: Caused by SAXParseException saying: cvc-complex-type.2.3: Element 'blueprint' cannot have character [children], because the type's content is element-only. My blueprint looks like following: ?xml version=1.0 encoding=utf-8? blueprint xmlns=http://www.osgi.org/xmlns/blueprint/v1.0.0; xmlns:tx=http://aries.apache.org/xmlns/transactions/v1.0.0; xmlns:jpa=http://aries.apache.org/xmlns/jpa/v1.1.0; bean id=testDAOBean class=ch.persistence.TestDAOImpl tx:transaction method=* value=Required/ jpa:context property=em unitname=herakles/ /bean /blueprint as I see, there are no character children. But what am I doing wrong? Thank you for help!
