It depends of what we are talking about.
I'm not sure that scala-based version of SMX (if we are talking about
SMX core code) is good thing.
However, be able to use Scala for SMX deployable artifacts or as a DSL
could be very interesting.
Regards
JB
On 07/01/2011 04:59 PM, Michael Van wrote:
From a geeking out perspective, the daunting task of moving SMX into Tomcat
seems like a good challenge to take on! Overcoming the traditional issues
of war-war communication using RMI would be tough, but the result could be a
better way of doing things inside of servlet containers, which I can see
being adopted by a very large community of developers. From that point of
view, I can see that this move will provide quite a bit of new utility to
all servlet developers. That improvement, along with the ability to run a
fully-fledged ESB inside of a servlet container would add a significant tool
to a servlet developers toolbox.
While we're at it, wouldn't it be great to see a scala-based version of SMX
also?
James Strachan wrote:
On 1 July 2011 15:32, Michael Van<[email protected]> wrote:
+1 to Ioannis point. Perhaps I've drank too much of the OSGi kool-aid,
but
moving from OSGi to Tomcat seems like a retrograde movement for SMX.
Noone said moving from OSGi; just supporting either Tomcat or Karaf
containers.
OSGi
solves quite a few problems that exist in Tomcat, especially from a
classloader perspective. There are just too many advantages of OSGi over
tomcat, and moving an application from OSGi to Tomcat to me is akin from
trading in your Prius for a Gremlin. Basically, its going backward in
technology with no real reason.
I hear you. It depends on how you look at it though. If you're happy
with Karaf, stick with it. If you're a user who's using Tomcat, knows
Tomcat really well (like most Java developers), has never touched OSGi
and has a bunch of existing WARs that just work (and probably don't
work in OSGi as you're probably using a ton of non-bundles), then the
Tomcat option is very appealing. Sometimes simpler is better (as
there's less to go wrong& you spend less time fighting with OSGi
metadata) - sometimes you want& need the power of OSGi.
Each to their own though; the container mechanism for building class
loaders should hopefully be quite separate to how ServiceMix adds
value to projects like ActiveMQ, Camel, CXF etc.
All that said, since the use of Camel/Karaf became mature, SMX's
viability
has been a question in my mind. Any change that shows the utility of SMX
over or in conjunction with Camel/Karaf is welcome.
Good luck!
Thanks! Its always worth remembering that ServiceMix kinda gave birth
to both Camel and Karaf :). Irrespective of what makes the class
loaders, I still think there's a ton of stuff that ServiceMix can do
to add value.
--
James
-------
FuseSource
Email: [email protected]
Web: http://fusesource.com
Twitter: jstrachan, fusenews
Blog: http://macstrac.blogspot.com/
Open Source Integration and Messaging
--
View this message in context:
http://servicemix.396122.n5.nabble.com/DISCUSS-Rebooting-ServiceMix-5-tp4528896p4542410.html
Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
