You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by Charles Moulliard <cm...@gmail.com> on 2009/04/02 10:16:18 UTC
SMX4 - proposition for future development
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),
- Add EJB3 support,
- Generate separate logs for bundles or features,
- Provide web admin interface,
- Clustering of SMX (based why not Camel on loadbalancing, integration with
terracota, ...),
- Propose architecture master/slave to deploy application from one server to
several SMX4 slaves,
- Improve feature to allow refresh or re installation of bundles,
- Integration with Eclipse to debug/deploy/undeploy application,
- Provide maven plugin to deploy/undeploy/stop/start bundles or project (=
list of features = list of bundles)
- For the administrator or profiler we need profiling to detect where we
have memory issues/gaps, ...
- Backup strategy,
- Rotation of the file logs (defined through etc config file or web
administration console)
- JMX support
- Alerting support in case or problem with bundles (active --> inactive)
Regards,
Charles Moulliard
SOA Architect
Re: SMX4 - proposition for future development
Posted by Guillaume Nodet <gn...@gmail.com>.
Trying to use JNDI from hibernate is imho a bad idea. How did you
expose the UserTransaction object in the JNDI tree ?
have you tried writing your own TransactionFactory for hibernate ?
The code is quite simple if you remove all the JNDI bits:
http://fisheye.jboss.com/browse/Hibernate/core/trunk/core/src/main/java/org/hibernate/transaction/JTATransactionFactory.java?r=15252
And looking at the above code, I don't really see how you can end up
with a StackOverflowError ... Not sure what happens here.
On Thu, Apr 2, 2009 at 14:44, Charles Moulliard <cm...@gmail.com> wrote:
> That was too beautiful.
>
> The same error comes back :
>
> org.hibernate.transaction.
> JTATransactionFactory.getUserTransaction(JTATransactionFactory.java:162)
> ...
>
> when I use the following config :
>
> <property name="jtaTransactionManager">
> <osgi:reference>
> <osgi:interfaces>
>
> <value>org.springframework.transaction.PlatformTransactionManager</value>
> <value>javax.transaction.TransactionManager</value>
> </osgi:interfaces>
> </osgi:reference>
> </property>
>
>
> On Thu, Apr 2, 2009 at 1:02 PM, Guillaume Nodet <gn...@gmail.com> wrote:
>
>> 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 <cm...@gmail.com>
>> 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 :
>> >
>> > smx@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 <gn...@gmail.com>
>> wrote:
>> >
>> >> On Thu, Apr 2, 2009 at 11:31, Charles Moulliard <cm...@gmail.com>
>> >> 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 <gn...@gmail.com>
>> >> wrote:
>> >> >
>> >> >> On Thu, Apr 2, 2009 at 10:16, Charles Moulliard <
>> cmoulliard@gmail.com>
>> >> >> 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
>>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: SMX4 - proposition for future development
Posted by Charles Moulliard <cm...@gmail.com>.
That was too beautiful.
The same error comes back :
org.hibernate.transaction.
JTATransactionFactory.getUserTransaction(JTATransactionFactory.java:162)
...
when I use the following config :
<property name="jtaTransactionManager">
<osgi:reference>
<osgi:interfaces>
<value>org.springframework.transaction.PlatformTransactionManager</value>
<value>javax.transaction.TransactionManager</value>
</osgi:interfaces>
</osgi:reference>
</property>
On Thu, Apr 2, 2009 at 1:02 PM, Guillaume Nodet <gn...@gmail.com> wrote:
> 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 <cm...@gmail.com>
> 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 :
> >
> > smx@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 <gn...@gmail.com>
> wrote:
> >
> >> On Thu, Apr 2, 2009 at 11:31, Charles Moulliard <cm...@gmail.com>
> >> 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 <gn...@gmail.com>
> >> wrote:
> >> >
> >> >> On Thu, Apr 2, 2009 at 10:16, Charles Moulliard <
> cmoulliard@gmail.com>
> >> >> 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
>
Re: SMX4 - proposition for future development
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <cm...@gmail.com> 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 :
>
> smx@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 <gn...@gmail.com> wrote:
>
>> On Thu, Apr 2, 2009 at 11:31, Charles Moulliard <cm...@gmail.com>
>> 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 <gn...@gmail.com>
>> wrote:
>> >
>> >> On Thu, Apr 2, 2009 at 10:16, Charles Moulliard <cm...@gmail.com>
>> >> 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
Re: SMX4 - proposition for future development
Posted by Charles Moulliard <cm...@gmail.com>.
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 :
smx@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 <gn...@gmail.com> wrote:
> On Thu, Apr 2, 2009 at 11:31, Charles Moulliard <cm...@gmail.com>
> 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 <gn...@gmail.com>
> wrote:
> >
> >> On Thu, Apr 2, 2009 at 10:16, Charles Moulliard <cm...@gmail.com>
> >> 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
>
Re: SMX4 - proposition for future development
Posted by Guillaume Nodet <gn...@gmail.com>.
On Thu, Apr 2, 2009 at 11:31, Charles Moulliard <cm...@gmail.com> 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 <gn...@gmail.com> wrote:
>
>> On Thu, Apr 2, 2009 at 10:16, Charles Moulliard <cm...@gmail.com>
>> 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
Re: SMX4 - proposition for future development
Posted by Charles Moulliard <cm...@gmail.com>.
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, ...
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
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)
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, ...
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
Regards,
Charles
On Thu, Apr 2, 2009 at 11:00 AM, Guillaume Nodet <gn...@gmail.com> wrote:
> On Thu, Apr 2, 2009 at 10:16, Charles Moulliard <cm...@gmail.com>
> 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
>
Re: SMX4 - proposition for future development
Posted by Charles Moulliard <cm...@gmail.com>.
I don't want to change it but as some bundles are already provided in this
file and installed, it is important to report somewhere such information in
case of recovery after a server update, ...
On Thu, Apr 2, 2009 at 4:50 PM, Guillaume Nodet <gn...@gmail.com> wrote:
> I think in all cases, if you want to manage a cluster of kernels,
> using the deploy folder is not necesseraly the best idea. Or just use
> rsync to copy over the changes then ... But having a full back up
> requires much more than that, it would need the preference services,
> the config admin, and all other configuration files in the /etc
> folder.
> Btw, what's your use case for changing the startup.properties file ?
>
> On Thu, Apr 2, 2009 at 16:45, Charles Moulliard <cm...@gmail.com>
> wrote:
> > Using features list as the installation contract is a good idea but in
> this
> > case, the deploy folder must be forbidden otherwise we will have a gap
> > between the content of the list + what is installed using deploy folder
> >
> > In resume : startup.properties + features list + folder deploy = list of
> > bundles to be backuped
> >
> >
> >
> > On Thu, Apr 2, 2009 at 4:27 PM, Guillaume Nodet <gn...@gmail.com>
> wrote:
> >
> >> On Thu, Apr 2, 2009 at 16:23, Jamie G. <ja...@gmail.com>
> wrote:
> >> > 1) Backup/recover config files
> >> >
> >> > Interesting, would be a useful feature.
> >> >
> >> > 2) Log rotation (already discussed)
> >> >
> >> > 3) Image of bundles installed..
> >> >
> >> > This sounds very useful to me, kind of like taking a system snapshot
> >> > that an administrator could roll back to if need be (great when dozens
> >> > of bundles are involved). Would this be another web admin interface
> >> > delivered feature or something we would do via the kernel shell
> >> > interface? I would assume the shell would be the best place for this
> >> > type of administrative function.
> >>
> >> I see a web console as offering the same features than the shell, so
> >> imho, everything available from the web should be available from the
> >> lower level shell also.
> >>
> >> What about building the rollback into the features service ? So that
> >> if the installation fails, it would leave the runtime in the same
> >> state that it was before installing the bundles. If everything is
> >> define by a feature, the state would only be the list of installed
> >> feature which may be way easier to manage.
> >>
> >> >
> >> > On Thu, Apr 2, 2009 at 11:05 AM, Charles Moulliard <
> cmoulliard@gmail.com>
> >> wrote:
> >> >> Concerning the backup strategy, I see two points :
> >> >>
> >> >> 1) Backup/recover config files
> >> >>
> >> >> This can be achieved through web admin interface. A zip file will be
> >> >> generated containing the config files and named according to the
> current
> >> >> system date. In case of trouble (after parameter modification or
> >> >> reinstallation), the user can reinstall files
> >> >>
> >> >> 2) Log rotation (already discussed) : can be defined in the existing
> cfg
> >> >> file
> >> >>
> >> >> 3) Keep image of the bundles installed (useful to roll back install
> of
> >> >> project = sum of bundles)
> >> >> With this feature, the deployer can be roll back an installation in
> case
> >> of
> >> >> problem
> >> >>
> >> >> Charles
> >> >>
> >> >>
> >> >> On Thu, Apr 2, 2009 at 3:16 PM, Jamie G. <ja...@gmail.com>
> >> wrote:
> >> >>
> >> >>> I'd like to know more about the Backup strategy too. Are we looking
> >> >>> for some best practices documentation or something more
> comprehensive
> >> >>> (such as disaster recovery scenario)?
> >> >>>
> >> >>> We already have some fail over support via the kernel as Guillaume
> has
> >> >>> noted.
> >> >>>
> >> >>> Cheers,
> >> >>> Jamie
> >> >>>
> >> >>> >> - Backup strategy,
> >> >>> >
> >> >>> > Please explain ? Is this related to
> >> >>> >
> >> >>>
> >>
> http://servicemix.apache.org/kernel/67-configuring-failover-deployments-available-in-110.html
> >> >>> > ?
> >> >>>
> >> >>
> >> >
> >>
> >>
> >>
> >> --
> >> 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
>
Re: SMX4 - proposition for future development
Posted by Guillaume Nodet <gn...@gmail.com>.
I think in all cases, if you want to manage a cluster of kernels,
using the deploy folder is not necesseraly the best idea. Or just use
rsync to copy over the changes then ... But having a full back up
requires much more than that, it would need the preference services,
the config admin, and all other configuration files in the /etc
folder.
Btw, what's your use case for changing the startup.properties file ?
On Thu, Apr 2, 2009 at 16:45, Charles Moulliard <cm...@gmail.com> wrote:
> Using features list as the installation contract is a good idea but in this
> case, the deploy folder must be forbidden otherwise we will have a gap
> between the content of the list + what is installed using deploy folder
>
> In resume : startup.properties + features list + folder deploy = list of
> bundles to be backuped
>
>
>
> On Thu, Apr 2, 2009 at 4:27 PM, Guillaume Nodet <gn...@gmail.com> wrote:
>
>> On Thu, Apr 2, 2009 at 16:23, Jamie G. <ja...@gmail.com> wrote:
>> > 1) Backup/recover config files
>> >
>> > Interesting, would be a useful feature.
>> >
>> > 2) Log rotation (already discussed)
>> >
>> > 3) Image of bundles installed..
>> >
>> > This sounds very useful to me, kind of like taking a system snapshot
>> > that an administrator could roll back to if need be (great when dozens
>> > of bundles are involved). Would this be another web admin interface
>> > delivered feature or something we would do via the kernel shell
>> > interface? I would assume the shell would be the best place for this
>> > type of administrative function.
>>
>> I see a web console as offering the same features than the shell, so
>> imho, everything available from the web should be available from the
>> lower level shell also.
>>
>> What about building the rollback into the features service ? So that
>> if the installation fails, it would leave the runtime in the same
>> state that it was before installing the bundles. If everything is
>> define by a feature, the state would only be the list of installed
>> feature which may be way easier to manage.
>>
>> >
>> > On Thu, Apr 2, 2009 at 11:05 AM, Charles Moulliard <cm...@gmail.com>
>> wrote:
>> >> Concerning the backup strategy, I see two points :
>> >>
>> >> 1) Backup/recover config files
>> >>
>> >> This can be achieved through web admin interface. A zip file will be
>> >> generated containing the config files and named according to the current
>> >> system date. In case of trouble (after parameter modification or
>> >> reinstallation), the user can reinstall files
>> >>
>> >> 2) Log rotation (already discussed) : can be defined in the existing cfg
>> >> file
>> >>
>> >> 3) Keep image of the bundles installed (useful to roll back install of
>> >> project = sum of bundles)
>> >> With this feature, the deployer can be roll back an installation in case
>> of
>> >> problem
>> >>
>> >> Charles
>> >>
>> >>
>> >> On Thu, Apr 2, 2009 at 3:16 PM, Jamie G. <ja...@gmail.com>
>> wrote:
>> >>
>> >>> I'd like to know more about the Backup strategy too. Are we looking
>> >>> for some best practices documentation or something more comprehensive
>> >>> (such as disaster recovery scenario)?
>> >>>
>> >>> We already have some fail over support via the kernel as Guillaume has
>> >>> noted.
>> >>>
>> >>> Cheers,
>> >>> Jamie
>> >>>
>> >>> >> - Backup strategy,
>> >>> >
>> >>> > Please explain ? Is this related to
>> >>> >
>> >>>
>> http://servicemix.apache.org/kernel/67-configuring-failover-deployments-available-in-110.html
>> >>> > ?
>> >>>
>> >>
>> >
>>
>>
>>
>> --
>> 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
Re: SMX4 - proposition for future development
Posted by Charles Moulliard <cm...@gmail.com>.
Using features list as the installation contract is a good idea but in this
case, the deploy folder must be forbidden otherwise we will have a gap
between the content of the list + what is installed using deploy folder
In resume : startup.properties + features list + folder deploy = list of
bundles to be backuped
On Thu, Apr 2, 2009 at 4:27 PM, Guillaume Nodet <gn...@gmail.com> wrote:
> On Thu, Apr 2, 2009 at 16:23, Jamie G. <ja...@gmail.com> wrote:
> > 1) Backup/recover config files
> >
> > Interesting, would be a useful feature.
> >
> > 2) Log rotation (already discussed)
> >
> > 3) Image of bundles installed..
> >
> > This sounds very useful to me, kind of like taking a system snapshot
> > that an administrator could roll back to if need be (great when dozens
> > of bundles are involved). Would this be another web admin interface
> > delivered feature or something we would do via the kernel shell
> > interface? I would assume the shell would be the best place for this
> > type of administrative function.
>
> I see a web console as offering the same features than the shell, so
> imho, everything available from the web should be available from the
> lower level shell also.
>
> What about building the rollback into the features service ? So that
> if the installation fails, it would leave the runtime in the same
> state that it was before installing the bundles. If everything is
> define by a feature, the state would only be the list of installed
> feature which may be way easier to manage.
>
> >
> > On Thu, Apr 2, 2009 at 11:05 AM, Charles Moulliard <cm...@gmail.com>
> wrote:
> >> Concerning the backup strategy, I see two points :
> >>
> >> 1) Backup/recover config files
> >>
> >> This can be achieved through web admin interface. A zip file will be
> >> generated containing the config files and named according to the current
> >> system date. In case of trouble (after parameter modification or
> >> reinstallation), the user can reinstall files
> >>
> >> 2) Log rotation (already discussed) : can be defined in the existing cfg
> >> file
> >>
> >> 3) Keep image of the bundles installed (useful to roll back install of
> >> project = sum of bundles)
> >> With this feature, the deployer can be roll back an installation in case
> of
> >> problem
> >>
> >> Charles
> >>
> >>
> >> On Thu, Apr 2, 2009 at 3:16 PM, Jamie G. <ja...@gmail.com>
> wrote:
> >>
> >>> I'd like to know more about the Backup strategy too. Are we looking
> >>> for some best practices documentation or something more comprehensive
> >>> (such as disaster recovery scenario)?
> >>>
> >>> We already have some fail over support via the kernel as Guillaume has
> >>> noted.
> >>>
> >>> Cheers,
> >>> Jamie
> >>>
> >>> >> - Backup strategy,
> >>> >
> >>> > Please explain ? Is this related to
> >>> >
> >>>
> http://servicemix.apache.org/kernel/67-configuring-failover-deployments-available-in-110.html
> >>> > ?
> >>>
> >>
> >
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
Re: SMX4 - proposition for future development
Posted by Guillaume Nodet <gn...@gmail.com>.
On Thu, Apr 2, 2009 at 16:23, Jamie G. <ja...@gmail.com> wrote:
> 1) Backup/recover config files
>
> Interesting, would be a useful feature.
>
> 2) Log rotation (already discussed)
>
> 3) Image of bundles installed..
>
> This sounds very useful to me, kind of like taking a system snapshot
> that an administrator could roll back to if need be (great when dozens
> of bundles are involved). Would this be another web admin interface
> delivered feature or something we would do via the kernel shell
> interface? I would assume the shell would be the best place for this
> type of administrative function.
I see a web console as offering the same features than the shell, so
imho, everything available from the web should be available from the
lower level shell also.
What about building the rollback into the features service ? So that
if the installation fails, it would leave the runtime in the same
state that it was before installing the bundles. If everything is
define by a feature, the state would only be the list of installed
feature which may be way easier to manage.
>
> On Thu, Apr 2, 2009 at 11:05 AM, Charles Moulliard <cm...@gmail.com> wrote:
>> Concerning the backup strategy, I see two points :
>>
>> 1) Backup/recover config files
>>
>> This can be achieved through web admin interface. A zip file will be
>> generated containing the config files and named according to the current
>> system date. In case of trouble (after parameter modification or
>> reinstallation), the user can reinstall files
>>
>> 2) Log rotation (already discussed) : can be defined in the existing cfg
>> file
>>
>> 3) Keep image of the bundles installed (useful to roll back install of
>> project = sum of bundles)
>> With this feature, the deployer can be roll back an installation in case of
>> problem
>>
>> Charles
>>
>>
>> On Thu, Apr 2, 2009 at 3:16 PM, Jamie G. <ja...@gmail.com> wrote:
>>
>>> I'd like to know more about the Backup strategy too. Are we looking
>>> for some best practices documentation or something more comprehensive
>>> (such as disaster recovery scenario)?
>>>
>>> We already have some fail over support via the kernel as Guillaume has
>>> noted.
>>>
>>> Cheers,
>>> Jamie
>>>
>>> >> - Backup strategy,
>>> >
>>> > Please explain ? Is this related to
>>> >
>>> http://servicemix.apache.org/kernel/67-configuring-failover-deployments-available-in-110.html
>>> > ?
>>>
>>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: SMX4 - proposition for future development
Posted by Charles Moulliard <cm...@gmail.com>.
Shell (and optionally web admin console)
Most of the time, such command will be placed in script file that the
administrator will receive for execution
On Thu, Apr 2, 2009 at 4:23 PM, Jamie G. <ja...@gmail.com> wrote:
> 1) Backup/recover config files
>
> Interesting, would be a useful feature.
>
> 2) Log rotation (already discussed)
>
> 3) Image of bundles installed..
>
> This sounds very useful to me, kind of like taking a system snapshot
> that an administrator could roll back to if need be (great when dozens
> of bundles are involved). Would this be another web admin interface
> delivered feature or something we would do via the kernel shell
> interface? I would assume the shell would be the best place for this
> type of administrative function.
>
> On Thu, Apr 2, 2009 at 11:05 AM, Charles Moulliard <cm...@gmail.com>
> wrote:
> > Concerning the backup strategy, I see two points :
> >
> > 1) Backup/recover config files
> >
> > This can be achieved through web admin interface. A zip file will be
> > generated containing the config files and named according to the current
> > system date. In case of trouble (after parameter modification or
> > reinstallation), the user can reinstall files
> >
> > 2) Log rotation (already discussed) : can be defined in the existing cfg
> > file
> >
> > 3) Keep image of the bundles installed (useful to roll back install of
> > project = sum of bundles)
> > With this feature, the deployer can be roll back an installation in case
> of
> > problem
> >
> > Charles
> >
> >
> > On Thu, Apr 2, 2009 at 3:16 PM, Jamie G. <ja...@gmail.com>
> wrote:
> >
> >> I'd like to know more about the Backup strategy too. Are we looking
> >> for some best practices documentation or something more comprehensive
> >> (such as disaster recovery scenario)?
> >>
> >> We already have some fail over support via the kernel as Guillaume has
> >> noted.
> >>
> >> Cheers,
> >> Jamie
> >>
> >> >> - Backup strategy,
> >> >
> >> > Please explain ? Is this related to
> >> >
> >>
> http://servicemix.apache.org/kernel/67-configuring-failover-deployments-available-in-110.html
> >> > ?
> >>
> >
>
Re: SMX4 - proposition for future development
Posted by "Jamie G." <ja...@gmail.com>.
1) Backup/recover config files
Interesting, would be a useful feature.
2) Log rotation (already discussed)
3) Image of bundles installed..
This sounds very useful to me, kind of like taking a system snapshot
that an administrator could roll back to if need be (great when dozens
of bundles are involved). Would this be another web admin interface
delivered feature or something we would do via the kernel shell
interface? I would assume the shell would be the best place for this
type of administrative function.
On Thu, Apr 2, 2009 at 11:05 AM, Charles Moulliard <cm...@gmail.com> wrote:
> Concerning the backup strategy, I see two points :
>
> 1) Backup/recover config files
>
> This can be achieved through web admin interface. A zip file will be
> generated containing the config files and named according to the current
> system date. In case of trouble (after parameter modification or
> reinstallation), the user can reinstall files
>
> 2) Log rotation (already discussed) : can be defined in the existing cfg
> file
>
> 3) Keep image of the bundles installed (useful to roll back install of
> project = sum of bundles)
> With this feature, the deployer can be roll back an installation in case of
> problem
>
> Charles
>
>
> On Thu, Apr 2, 2009 at 3:16 PM, Jamie G. <ja...@gmail.com> wrote:
>
>> I'd like to know more about the Backup strategy too. Are we looking
>> for some best practices documentation or something more comprehensive
>> (such as disaster recovery scenario)?
>>
>> We already have some fail over support via the kernel as Guillaume has
>> noted.
>>
>> Cheers,
>> Jamie
>>
>> >> - Backup strategy,
>> >
>> > Please explain ? Is this related to
>> >
>> http://servicemix.apache.org/kernel/67-configuring-failover-deployments-available-in-110.html
>> > ?
>>
>
Re: SMX4 - proposition for future development
Posted by Charles Moulliard <cm...@gmail.com>.
Concerning the backup strategy, I see two points :
1) Backup/recover config files
This can be achieved through web admin interface. A zip file will be
generated containing the config files and named according to the current
system date. In case of trouble (after parameter modification or
reinstallation), the user can reinstall files
2) Log rotation (already discussed) : can be defined in the existing cfg
file
3) Keep image of the bundles installed (useful to roll back install of
project = sum of bundles)
With this feature, the deployer can be roll back an installation in case of
problem
Charles
On Thu, Apr 2, 2009 at 3:16 PM, Jamie G. <ja...@gmail.com> wrote:
> I'd like to know more about the Backup strategy too. Are we looking
> for some best practices documentation or something more comprehensive
> (such as disaster recovery scenario)?
>
> We already have some fail over support via the kernel as Guillaume has
> noted.
>
> Cheers,
> Jamie
>
> >> - Backup strategy,
> >
> > Please explain ? Is this related to
> >
> http://servicemix.apache.org/kernel/67-configuring-failover-deployments-available-in-110.html
> > ?
>
Re: SMX4 - proposition for future development
Posted by "Jamie G." <ja...@gmail.com>.
I'd like to know more about the Backup strategy too. Are we looking
for some best practices documentation or something more comprehensive
(such as disaster recovery scenario)?
We already have some fail over support via the kernel as Guillaume has noted.
Cheers,
Jamie
>> - Backup strategy,
>
> Please explain ? Is this related to
> http://servicemix.apache.org/kernel/67-configuring-failover-deployments-available-in-110.html
> ?
Re: SMX4 - proposition for future development
Posted by Guillaume Nodet <gn...@gmail.com>.
On Thu, Apr 2, 2009 at 10:16, Charles Moulliard <cm...@gmail.com> 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