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 <[email protected]> wrote: > On Thu, Apr 2, 2009 at 10:16, Charles Moulliard <[email protected]> > wrote: > > Hi, > > > > Here is a list of features that I think could be interesting to implement > in > > future versions of SMX Kernel : > > > > - Improve JNDI support and integration with JTA transaction management > (to > > have one manager by SMX server), > > Could you elaborate a bit please ? Do you mean exposing the > transaction manager in the JNDI tree ? > We can do that easily I think, but I would advise to retrieve a > reference to the transaction manager from the OSGi registry and use it > directly if possible. JNDI/OSGi integration has to be limited wrt to > OSGi classloading and OSGi service dynamics, so it's best to keep away > from JNDI if possible. > > > - Add EJB3 support, > > Imho, this is a good thing to have (I guess you mean the ability to > host an EJB3 container and deploy EJB3 as OSGi bundles). I started > some work around that a long time ago, but never has any time to > finish. I think the OpenEJB people have done some work around OSGi so > it could be worth asking them. > That said, I don't really think it should be part of ServiceMix Kernel > distribution, but rather available as a feature like activemq, camel, > etc... > > > - Generate separate logs for bundles or features, > > Yeah, there's a jira that you raised some time ago already. > > > - Provide web admin interface, > > Yes, we've been discussing this need at ApacheCon a bit and there's a > GsoC project around that. > Actually, I think we should have a look at the Felix console which > already provides OSGi management (bundles, services, configurations, > etc...) and is extensible. > > > - Clustering of SMX (based why not Camel on loadbalancing, integration > with > > terracota, ...), > > Clustering is a very large idea. What kind of things would you want > to cluster ? Web apps ? Camel routes ? > > > - Propose architecture master/slave to deploy application from one server > to > > several SMX4 slaves, > > Progress is working on an open source tool around that, I'll blog more > about it when it's available .. > > > - Improve feature to allow refresh or re installation of bundles, > > Yes, there's a jira about that too. That's something we really need > to fix asap, but unfortunately, I don't have any good idea yet. The > only thing > > > - Integration with Eclipse to debug/deploy/undeploy application, > > +1 > > > - Provide maven plugin to deploy/undeploy/stop/start bundles or project > (= > > list of features = list of bundles) > > We have such a plugin(features-maven-plugin) and we're already working > on integrating deployment capabilities in it. > > > - For the administrator or profiler we need profiling to detect where we > > have memory issues/gaps, ... > > How can ServiceMix Kernel help on that ? I don't see us developing a > profiling tool. > > > - Backup strategy, > > Please explain ? Is this related to > > http://servicemix.apache.org/kernel/67-configuring-failover-deployments-available-in-110.html > ? > > > - Rotation of the file logs (defined through etc config file or web > > administration console) > > Isn't that just a configuration change in the underlying log4j system ? > > > - JMX support > > We already have JMX support. What are you looking for exactly ? > > > - Alerting support in case or problem with bundles (active --> inactive) > > This should be possible through JMX and notifications I guess, using > any JMX monitoring application. > > > Regards, > > > > Charles Moulliard > > SOA Architect > > > > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com >
