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
>

Reply via email to