The second way should work. Your problem is that you're not importing both the TransactionManager and PlatformTransactionManager interfaces. Take a look at http://static.springframework.org/osgi/docs/1.2.0-rc1/reference/html/service-registry.html#service-registry:refs:singular:interface
On Thu, Apr 2, 2009 at 12:16, Charles Moulliard <[email protected]> wrote: > The Transaction manager in ServiceMix 4 is already a Spring > PlaftormTransactionManager, so you should just use this one instead. > >>> I have tested this option but I receive errors > > *CASE 1 : using JTA Transaction Manager* > > <!-- Hibernate SessionFactory Definition --> > <bean id="sessionFactory" > class="org.springframework.orm.hibernate3.LocalSessionFactoryBean"> > > <property name="mappingLocations"> > <list> > > <value>classpath*:META-INF/org/apache/camel/example/reportincident/model/*.hbm.xml</value> > </list> > </property> > > <property name="hibernateProperties"> > <props> > <prop > key="hibernate.dialect">org.hibernate.dialect.MySQLDialect</prop> > <prop key="hibernate.show_sql">false</prop> > <prop key="hibernate.format_sql">true</prop> > <prop > key="hibernate.cglib.use_reflection_optimizer">true</prop> > <prop key="hibernate.jdbc.batch_size">10</prop> > <!-- <prop > key="hibernate.transaction.factory_class">org.hibernate.transaction.JTATransactionFactory</prop> > --> > </props> > </property> > <property name="dataSource"> > <ref bean="dataSource" /> > </property> > <property name="jtaTransactionManager"> > <osgi:reference > interface="javax.transaction.TransactionManager"/> > </property> > </bean> > > java.lang.StackOverflowError > at > com.sun.naming.internal.VersionHelper12$6.run(VersionHelper12.java:165) > at java.security.AccessController.doPrivileged(Native Method) > at > com.sun.naming.internal.VersionHelper12.getContextClassLoader(VersionHelper12.java:162) > at > com.sun.naming.internal.ResourceManager.getFactory(ResourceManager.java:339) > at javax.naming.spi.NamingManager.getURLObject(NamingManager.java:575) > at javax.naming.spi.NamingManager.getURLContext(NamingManager.java:533) > at > javax.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:320) > at javax.naming.InitialContext.lookup(InitialContext.java:392) > at > org.hibernate.transaction.JTATransactionFactory.getUserTransaction(JTATransactionFactory.java:162) > at > org.hibernate.transaction.JTATransactionFactory.getUserTransaction(JTATransactionFactory.java:172) > at > org.hibernate.transaction.JTATransactionFactory.getUserTransaction(JTATransactionFactory.java:172) > at > org.hibernate.transaction.JTATransactionFactory.getUserTransaction(JTATransactionFactory.java:172) > at > org.hibernate.transaction.JTATransactionFactory.getUserTransaction(JTATransactionFactory.java:172) > > *CASE 1 : using PlatformTransactionManager*** > > when I use > <property name="jtaTransactionManager"> > <osgi:reference > interface="org.springframework.transaction.PlatformTransactionManager"/> > </property> > > instead of JTA Transaction Manager > > I receive the error : > > s...@root:osgi> Exception in thread "SpringOsgiExtenderThread-40" > org.springframework.beans.factory.BeanCreationException: Error creating bean > with name 'org.springframewo > rk.osgi.service.exporter.support.OsgiServiceFactoryBean#0': Invocation of > init method failed; nested exception is > org.springframework.beans.factory.BeanCreationException: > Error creating bean with name 'incidentDAO' defined in URL > [bundle://113.2:0/META-INF/spring/spring-dao-beans.xml]: Cannot resolve > reference to bean 'sessionFactory' whi > le setting bean property 'sessionFactory'; nested exception is > org.springframework.beans.factory.BeanCreationException: Error creating bean > with name 'sessionFactory' def > ined in URL [bundle://113.2:0/META-INF/spring/spring-datasource-beans.xml]: > Initialization of bean failed; nested exception is > org.springframework.beans.TypeMismatchExcep > tion: Failed to convert property value of type [$Proxy114 implementing > org.springframework.transaction.PlatformTransactionManager,java.io.Serializable,org.springframework > .osgi.service.importer.ImportedOsgiServiceProxy,org.springframework.aop.IntroductionInfo,org.springframework.core.InfrastructureProxy,org.springframework.aop.SpringProxy] > to required type [javax.transaction.TransactionManager] for property > 'jtaTransactionManager'; nested exception is > java.lang.IllegalArgumentException: Cannot convert valu > e of type [$Proxy114 implementing > org.springframework.transaction.PlatformTransactionManager,java.io.Serializable,org.springframework.osgi.service.importer.ImportedOsgiSe > rviceProxy,org.springframework.aop.IntroductionInfo,org.springframework.core.InfrastructureProxy,org.springframework.aop.SpringProxy] > to required type [javax.transaction. > TransactionManager] for property 'jtaTransactionManager': no matching > editors or conversion strategy found > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1338) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:473) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory$1.run(AbstractAutowireCapableBeanFactory.java:409) > at java.security.AccessController.doPrivileged(Native Method) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:380) > at > org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:264) > at > org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222) > at > org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:261) > at > org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:185) > at > org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:164) > at > org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:423) > at > org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:728) > at > org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.access$1600(AbstractDelegatedExecutionApplicationContext.java:69) > at > org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext$4.run(AbstractDelegatedExecutionApplicationContext.java:355) > at > org.springframework.osgi.util.internal.PrivilegedUtils.executeWithCustomTCCL(PrivilegedUtils.java:85) > at > org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.completeRefresh(AbstractDelegatedExecutionApplicationContext.java:320) > at > org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor$CompleteRefreshTask.run(DependencyWaiterApplicationC > ontextExecutor.java:136) > at java.lang.Thread.run(Thread.java:619) > > > On Thu, Apr 2, 2009 at 11:42 AM, Guillaume Nodet <[email protected]> wrote: > >> On Thu, Apr 2, 2009 at 11:31, Charles Moulliard <[email protected]> >> wrote: >> > Could you elaborate a bit please ? >> > >> >>> My idea is to propose to the users JNDI feature like we have with J2EE >> > servers. I mean a Web interface and/or configuration that a user/deployer >> > can use to add entries like DataSource (+ info about DB connection), >> > UserTransaction, ... >> >> As I said, JNDI does not really fit well with OSGi, so for all such >> kinds of thing like deploying DataSource, I would rather expose the >> service in the OSGi registry. Binding it to JNDI should remain >> optional so that users are encouraged to use the OSGi registry >> instead. If you use a spring application, it's kinda the same thing >> to retrieve the DataSource from JNDI or OSGi, and most of the >> applications should be able be given an existing DataSource instead of >> retrieving it from JNDI. >> >> > Do you mean exposing the >> > transaction manager in the JNDI tree ? >> > >> >>> Yes. In this case, we can use the same transaction manager to handle >> > commit/rollback between endpoints like JMS, Hibernate or Spring/Beans >> using >> > JTATransaction Manager. This is not possible today because using >> > JTATransaction manager in Spring requires that the transaction manager is >> > registered in a JNDI context >> >> The Transaction manager in ServiceMix 4 is already a Spring >> PlaftormTransactionManager, so you should just use this one instead. >> >> > >> > Concerning EJB3 >> >>> I complety agrees with you : openEJB is an excellent candidate and this >> > should not be part of SMX Kernel but deployable as an feature and >> probably >> > in the future available from another instance of SMX using by exampel >> remote >> > OSGI >> > >> > Actually, I think we should have a look at the Felix console which >> > already provides OSGi management (bundles, services, configurations, >> > etc...) and is extensible. >> > >> >>> I have already deploy it in SMX Kernel. It works except that we can >> stop >> > the "mandatory bundles" I mean bundles with level < 30 >> > The web console should be extended to allow JNDI configuration, log >> rotation >> > definition, ... (we can have a look to glassfish to compare) >> >> Maybe that can be enhanced somehow. >> >> > Clustering is a very large idea. What kind of things would you want >> > to cluster ? Web apps ? Camel routes ? >> > >> >>> My idea is to provide something simple to be used by the user where he >> > can define in config file : >> > - The numbers of instances required (in a first step, we can propose that >> > the instances are started locally on a machine X and in the second step >> on >> > another machines and interconnected through remote OSGI), >> > - Type of clustering : camel loadbalancing, ... (e.g. If camel routes >> must >> > be copied on each instance or used in a load balancing way ), web (for >> web >> > farm) >> > - Integration type between instances, machines, servers : using activemq >> as >> > queue engine between instances, remote OSGI, ... (be careful about >> firewall) >> > This question is very complicated because it really depends also of the >> > architecture like : can we scan same directory from different instances >> of >> > camel-file, ... >> >> I don't think any of those features is related to ServiceMix Kernel, >> rather to ServiceMix 4 as an integration platform. >> And as you say, it's quite a difficult thing to achieve. That does >> not mean we can't do anything to help users here. >> >> > >> > For the administrator or profiler we need profiling to detect where we >> > have memory issues/gaps, .. >> > >> >>> SMX4 cannot do anything but we should be able to configure SMX + java >> to >> > allow java profiling >> >> So it's just about documenting that cleanly, as I don't think there is >> anything to do. >> >> > Regards, >> > >> > Charles >> > >> > On Thu, Apr 2, 2009 at 11:00 AM, Guillaume Nodet <[email protected]> >> wrote: >> > >> >> On Thu, Apr 2, 2009 at 10:16, Charles Moulliard <[email protected]> >> >> wrote: >> >> > Hi, >> >> > >> >> > Here is a list of features that I think could be interesting to >> implement >> >> in >> >> > future versions of SMX Kernel : >> >> > >> >> > - Improve JNDI support and integration with JTA transaction management >> >> (to >> >> > have one manager by SMX server), >> >> >> >> Could you elaborate a bit please ? Do you mean exposing the >> >> transaction manager in the JNDI tree ? >> >> We can do that easily I think, but I would advise to retrieve a >> >> reference to the transaction manager from the OSGi registry and use it >> >> directly if possible. JNDI/OSGi integration has to be limited wrt to >> >> OSGi classloading and OSGi service dynamics, so it's best to keep away >> >> from JNDI if possible. >> >> >> >> > - Add EJB3 support, >> >> >> >> Imho, this is a good thing to have (I guess you mean the ability to >> >> host an EJB3 container and deploy EJB3 as OSGi bundles). I started >> >> some work around that a long time ago, but never has any time to >> >> finish. I think the OpenEJB people have done some work around OSGi so >> >> it could be worth asking them. >> >> That said, I don't really think it should be part of ServiceMix Kernel >> >> distribution, but rather available as a feature like activemq, camel, >> >> etc... >> >> >> >> > - Generate separate logs for bundles or features, >> >> >> >> Yeah, there's a jira that you raised some time ago already. >> >> >> >> > - Provide web admin interface, >> >> >> >> Yes, we've been discussing this need at ApacheCon a bit and there's a >> >> GsoC project around that. >> >> Actually, I think we should have a look at the Felix console which >> >> already provides OSGi management (bundles, services, configurations, >> >> etc...) and is extensible. >> >> >> >> > - Clustering of SMX (based why not Camel on loadbalancing, integration >> >> with >> >> > terracota, ...), >> >> >> >> Clustering is a very large idea. What kind of things would you want >> >> to cluster ? Web apps ? Camel routes ? >> >> >> >> > - Propose architecture master/slave to deploy application from one >> server >> >> to >> >> > several SMX4 slaves, >> >> >> >> Progress is working on an open source tool around that, I'll blog more >> >> about it when it's available .. >> >> >> >> > - Improve feature to allow refresh or re installation of bundles, >> >> >> >> Yes, there's a jira about that too. That's something we really need >> >> to fix asap, but unfortunately, I don't have any good idea yet. The >> >> only thing >> >> >> >> > - Integration with Eclipse to debug/deploy/undeploy application, >> >> >> >> +1 >> >> >> >> > - Provide maven plugin to deploy/undeploy/stop/start bundles or >> project >> >> (= >> >> > list of features = list of bundles) >> >> >> >> We have such a plugin(features-maven-plugin) and we're already working >> >> on integrating deployment capabilities in it. >> >> >> >> > - For the administrator or profiler we need profiling to detect where >> we >> >> > have memory issues/gaps, ... >> >> >> >> How can ServiceMix Kernel help on that ? I don't see us developing a >> >> profiling tool. >> >> >> >> > - Backup strategy, >> >> >> >> Please explain ? Is this related to >> >> >> >> >> http://servicemix.apache.org/kernel/67-configuring-failover-deployments-available-in-110.html >> >> ? >> >> >> >> > - Rotation of the file logs (defined through etc config file or web >> >> > administration console) >> >> >> >> Isn't that just a configuration change in the underlying log4j system ? >> >> >> >> > - JMX support >> >> >> >> We already have JMX support. What are you looking for exactly ? >> >> >> >> > - Alerting support in case or problem with bundles (active --> >> inactive) >> >> >> >> This should be possible through JMX and notifications I guess, using >> >> any JMX monitoring application. >> >> >> >> > Regards, >> >> > >> >> > Charles Moulliard >> >> > SOA Architect >> >> > >> >> >> >> >> >> >> >> -- >> >> Cheers, >> >> Guillaume Nodet >> >> ------------------------ >> >> Blog: http://gnodet.blogspot.com/ >> >> ------------------------ >> >> Open Source SOA >> >> http://fusesource.com >> >> >> > >> >> >> >> -- >> Cheers, >> Guillaume Nodet >> ------------------------ >> Blog: http://gnodet.blogspot.com/ >> ------------------------ >> Open Source SOA >> http://fusesource.com >> > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
