You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by Guillaume Nodet <gn...@gmail.com> on 2011/06/27 17:54:39 UTC
[DISCUSS] Rebooting ServiceMix 5
Last week, I've been discussing with a few committers about the
ServiceMix roadmap.
So I'd like to communicate those thoughts to a wider audience.
We've been discussing already that the value of ServiceMix (which was
the JBI layer in ServiceMix 3
and the container side in ServiceMix 4) has moved mostly to Camel and
Karaf respectively. The remainining
bits are mostly the NMR. However, the value of the NMR is not in the
NMR itself, but rather the NMR was
supposed to enable various container-level features. However, we
haven't really built those features so
that the *real* value of the NMR is not that high currently.
So, what we've been discussing is to focus on that added value in a
more transparent way by tweaking
Camel a bit to support global interceptors, so that one could deploy
the real routes without having to
force the use of a specific transport such as the current NMR. This
way, a user could test / develop
the Camel routes or take existing Camel routes and deploy them in
ServiceMix, thereby transparently
enabling a bunch of useful features. We've been thinking about adding
message tracing / timing / auditing,
sending test messages, security checks, viewing flows, persistent
modification of camel
routes, camel route versioning, etc... That need to be coupled with a
web console similar to the
Camel / ActiveMQ web consoles, to actually display all the data to
provide useful information for monitoring
Camel routes and help diagnosing problems in production for example.
There's really nothing magically new
here and some of those features were actually part of ServiceMix 3,
but without much focus on those and
they have always kept a bit on the side. The idea is really to make
ServiceMix the best possible container
for deploying Camel based integration.
Additional things that could be pushed inside ServiceMix 5 would be a
Tomcat based container deployment
option (for those that don't need OSGi), a new manual similar to what
we have in Karaf (maybe reusing
parts of it). We'd also need a new website (without the technical
doc, as we have for Karaf I think).
On the maintenance of the JBI components and NMR/JBI layer, I think we
should keep them in smx4.
People wanting to deploy those could easily add a pointer to the
servicemix 4 features descriptors and
deploy the needed features. So we could officially deprecate those
and tell users they won't be
available in smx5. This also means that there's really not much to
reuse from smx4, so smx5 would
have its own new and dedicated svn area.
FWIW, I plan to devote a big chunk of my time on ServiceMix 5 in the
coming months, so those are not
faithful wishes, but really something I want to start implementing asap.
Feedback welcomed!
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSS] Rebooting ServiceMix 5
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Thanks a bunch,
I saw the svn commit.
Regards
JB
On 06/29/2011 03:11 PM, Guillaume Nodet wrote:
> I've just create a svn repository
> http://svn.apache.org/repos/asf/servicemix/smx5/trunk
> and a JIRA for a git mirror
> https://issues.apache.org/jira/browse/INFRA-3736
>
> On Mon, Jun 27, 2011 at 17:54, Guillaume Nodet<gn...@gmail.com> wrote:
>> Last week, I've been discussing with a few committers about the
>> ServiceMix roadmap.
>> So I'd like to communicate those thoughts to a wider audience.
>>
>> We've been discussing already that the value of ServiceMix (which was
>> the JBI layer in ServiceMix 3
>> and the container side in ServiceMix 4) has moved mostly to Camel and
>> Karaf respectively. The remainining
>> bits are mostly the NMR. However, the value of the NMR is not in the
>> NMR itself, but rather the NMR was
>> supposed to enable various container-level features. However, we
>> haven't really built those features so
>> that the *real* value of the NMR is not that high currently.
>>
>> So, what we've been discussing is to focus on that added value in a
>> more transparent way by tweaking
>> Camel a bit to support global interceptors, so that one could deploy
>> the real routes without having to
>> force the use of a specific transport such as the current NMR. This
>> way, a user could test / develop
>> the Camel routes or take existing Camel routes and deploy them in
>> ServiceMix, thereby transparently
>> enabling a bunch of useful features. We've been thinking about adding
>> message tracing / timing / auditing,
>> sending test messages, security checks, viewing flows, persistent
>> modification of camel
>> routes, camel route versioning, etc... That need to be coupled with a
>> web console similar to the
>> Camel / ActiveMQ web consoles, to actually display all the data to
>> provide useful information for monitoring
>> Camel routes and help diagnosing problems in production for example.
>> There's really nothing magically new
>> here and some of those features were actually part of ServiceMix 3,
>> but without much focus on those and
>> they have always kept a bit on the side. The idea is really to make
>> ServiceMix the best possible container
>> for deploying Camel based integration.
>>
>> Additional things that could be pushed inside ServiceMix 5 would be a
>> Tomcat based container deployment
>> option (for those that don't need OSGi), a new manual similar to what
>> we have in Karaf (maybe reusing
>> parts of it). We'd also need a new website (without the technical
>> doc, as we have for Karaf I think).
>>
>> On the maintenance of the JBI components and NMR/JBI layer, I think we
>> should keep them in smx4.
>> People wanting to deploy those could easily add a pointer to the
>> servicemix 4 features descriptors and
>> deploy the needed features. So we could officially deprecate those
>> and tell users they won't be
>> available in smx5. This also means that there's really not much to
>> reuse from smx4, so smx5 would
>> have its own new and dedicated svn area.
>>
>> FWIW, I plan to devote a big chunk of my time on ServiceMix 5 in the
>> coming months, so those are not
>> faithful wishes, but really something I want to start implementing asap.
>>
>> Feedback welcomed!
>>
>> --
>> ------------------------
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>
>
>
Re: [DISCUSS] Rebooting ServiceMix 5
Posted by Guillaume Nodet <gn...@gmail.com>.
I've just create a svn repository
http://svn.apache.org/repos/asf/servicemix/smx5/trunk
and a JIRA for a git mirror
https://issues.apache.org/jira/browse/INFRA-3736
On Mon, Jun 27, 2011 at 17:54, Guillaume Nodet <gn...@gmail.com> wrote:
> Last week, I've been discussing with a few committers about the
> ServiceMix roadmap.
> So I'd like to communicate those thoughts to a wider audience.
>
> We've been discussing already that the value of ServiceMix (which was
> the JBI layer in ServiceMix 3
> and the container side in ServiceMix 4) has moved mostly to Camel and
> Karaf respectively. The remainining
> bits are mostly the NMR. However, the value of the NMR is not in the
> NMR itself, but rather the NMR was
> supposed to enable various container-level features. However, we
> haven't really built those features so
> that the *real* value of the NMR is not that high currently.
>
> So, what we've been discussing is to focus on that added value in a
> more transparent way by tweaking
> Camel a bit to support global interceptors, so that one could deploy
> the real routes without having to
> force the use of a specific transport such as the current NMR. This
> way, a user could test / develop
> the Camel routes or take existing Camel routes and deploy them in
> ServiceMix, thereby transparently
> enabling a bunch of useful features. We've been thinking about adding
> message tracing / timing / auditing,
> sending test messages, security checks, viewing flows, persistent
> modification of camel
> routes, camel route versioning, etc... That need to be coupled with a
> web console similar to the
> Camel / ActiveMQ web consoles, to actually display all the data to
> provide useful information for monitoring
> Camel routes and help diagnosing problems in production for example.
> There's really nothing magically new
> here and some of those features were actually part of ServiceMix 3,
> but without much focus on those and
> they have always kept a bit on the side. The idea is really to make
> ServiceMix the best possible container
> for deploying Camel based integration.
>
> Additional things that could be pushed inside ServiceMix 5 would be a
> Tomcat based container deployment
> option (for those that don't need OSGi), a new manual similar to what
> we have in Karaf (maybe reusing
> parts of it). We'd also need a new website (without the technical
> doc, as we have for Karaf I think).
>
> On the maintenance of the JBI components and NMR/JBI layer, I think we
> should keep them in smx4.
> People wanting to deploy those could easily add a pointer to the
> servicemix 4 features descriptors and
> deploy the needed features. So we could officially deprecate those
> and tell users they won't be
> available in smx5. This also means that there's really not much to
> reuse from smx4, so smx5 would
> have its own new and dedicated svn area.
>
> FWIW, I plan to devote a big chunk of my time on ServiceMix 5 in the
> coming months, so those are not
> faithful wishes, but really something I want to start implementing asap.
>
> Feedback welcomed!
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSS] Rebooting ServiceMix 5
Posted by James Strachan <ja...@fusesource.com>.
On 1 July 2011 11:01, Ioannis Canellos <io...@gmail.com> wrote:
>> I'm not even sure that's possible :). Using ServiceMix in a Tomcat
>> distro would be more about "reusing Tomcat" than "taking full
>> advantage of OSGi".
>>
>
> Please allow me to rephrase: "How can we build a product, that will run both
> on Tomcat and Karaf, without limiting the pure Karaf deployments".
> It's not a statement. Its more like a technical concern.
Totally agreed BTW. I think its totally fine for some stuff to only
work in OSGi land and some stuff to be a bit 'hard baked' into Tomcat.
--
James
-------
FuseSource
Email: james@fusesource.com
Web: http://fusesource.com
Twitter: jstrachan, fusenews
Blog: http://macstrac.blogspot.com/
Open Source Integration and Messaging
Re: [DISCUSS] Rebooting ServiceMix 5
Posted by Ioannis Canellos <io...@gmail.com>.
> I'm not even sure that's possible :). Using ServiceMix in a Tomcat
> distro would be more about "reusing Tomcat" than "taking full
> advantage of OSGi".
>
Please allow me to rephrase: "How can we build a product, that will run both
on Tomcat and Karaf, without limiting the pure Karaf deployments".
It's not a statement. Its more like a technical concern.
> Tomcat and Karaf both rock and both have their pros and cons; though
> letting users choose is a good thing too IMHO.
>
Despite my technical concerns, I totally agree on that.
--
*Ioannis Canellos*
*
http://iocanel.blogspot.com
Apache Karaf <http://karaf.apache.org/> Committer & PMC
Apache ServiceMix <http://servicemix.apache.org/> Committer
*
Re: [DISCUSS] Rebooting ServiceMix 5
Posted by James Strachan <ja...@fusesource.com>.
On 1 July 2011 09:58, Ioannis Canellos <io...@gmail.com> wrote:
> My comment about being skeptic about Tomcat received a lot of comments, so I
> would like to clarify that I am not being skeptic on "if we should support
> tomcat" but on "how can we support tomcat + take full advantage of OSGi".
I'm not even sure that's possible :). Using ServiceMix in a Tomcat
distro would be more about "reusing Tomcat" than "taking full
advantage of OSGi".
It will be interesting to see how OSGi-like we can make Tomcat, but
I'd have thought the shared class loader stuff in Tomcat is always
going to be fairly static though; not like OSGi where anything can be
hot swapped at runtime and by using wacky class loaders you can hide
packages or share different versions of the same package across
deployment units. WARs can clearly be hot-swapped; am not sure if
there'll be any hot swapping of the shared ServiceMix class loader
stuff though.
Though maybe its a bit like using statically typed languages like
Scala in a REPL (which makes it seem like a totally dynamic scripting
language when really its just compiling each line on the fly); we
could maybe make the Tomcat version of ServiceMix look and feel like
the dynamic OSGi world; its just when you upgrade/install/uninstall
something shared, it just reboots Tomcat under the covers :). But then
folks in production with Tomcat tend to do that anyway when
undeploying WARs anyway :)
Its worth remembering though that the aim isn't to turn Tomcat into
OSGi (there's no point, there's already OSGi/Karaf if thats what you
want :), its to bring the ServiceMix goodness to folks who prefer
Tomcat as their general purpose application container.
Tomcat and Karaf both rock and both have their pros and cons; though
letting users choose is a good thing too IMHO.
--
James
-------
FuseSource
Email: james@fusesource.com
Web: http://fusesource.com
Twitter: jstrachan, fusenews
Blog: http://macstrac.blogspot.com/
Open Source Integration and Messaging
Re: [DISCUSS] Rebooting ServiceMix 5
Posted by Ioannis Canellos <io...@gmail.com>.
My comment about being skeptic about Tomcat received a lot of comments, so I
would like to clarify that I am not being skeptic on "if we should support
tomcat" but on "how can we support tomcat + take full advantage of OSGi".
--
*Ioannis Canellos*
*
http://iocanel.blogspot.com
Apache Karaf <http://karaf.apache.org/> Committer & PMC
Apache ServiceMix <http://servicemix.apache.org/> Committer
*
Re: [DISCUSS] Rebooting ServiceMix 5
Posted by Guillaume Nodet <gn...@gmail.com>.
On Fri, Jul 1, 2011 at 10:41, Claus Ibsen <cl...@gmail.com> wrote:
> On Fri, Jul 1, 2011 at 10:13 AM, James Strachan <ja...@fusesource.com> wrote:
>> On 29 June 2011 10:14, Geert Schuring <ge...@schuring.eu> wrote:
>>> I too have doubts about the Tomcat distribution. The software stack that
>>> ServiceMix consists of is already very complex, and contains all kinds of
>>> frameworks and components that can be used outside ServiceMix or OSGi as
>>> well. In my opinion ServiceMix should focus on providing a consistent, well
>>> documented environment instead of trying to serve as much different ways of
>>> implementation as possible. I think that's an important reason why the
>>> documentation has been so slow and painful for SMX 3 & 4.
>>>
>>> I think starting new documenation from scratch for SMX 5 is a very good
>>> idea. Combined with using scalate and storing the documentation in
>>> subversion, we should be able to write version specific and accurate
>>> documentation.
>>>
>>> Would it be possible to drop spring entirely and switch to blueprint for SMX
>>> 5? That again would simplify the examples and documentation, and would make
>>> SMX 5 more accessible to new users.
>>
>> An ESB is all about integration; so dropping support for things people
>> use is generally bad; though for sure we should recommend on OSGi
>> folks use blueprint as its simpler & smaller; though we should still
>> support folks using Spring.
>>
>
> Yeah Spring is widely used. Its just that spring-dm is ... not their
> finest moment.
> Maybe that Eclipse Virgo is better (isnt that spring-dm 2.0).
The ideas in spring-dm are really good, I think the main problem is
that they had the requirement to support spring namespaces with no
changes, and that it does not fit well in OSGi. The Aries blueprint
impl did not had such constraints, so it was easier to have something
better ;-)
>
>> --
>> James
>> -------
>> FuseSource
>> Email: james@fusesource.com
>> Web: http://fusesource.com
>> Twitter: jstrachan, fusenews
>> Blog: http://macstrac.blogspot.com/
>>
>> Open Source Integration and Messaging
>>
>
>
>
> --
> Claus Ibsen
> -----------------
> FuseSource
> Email: cibsen@fusesource.com
> Web: http://fusesource.com
> Twitter: davsclaus, fusenews
> Blog: http://davsclaus.blogspot.com/
> Author of Camel in Action: http://www.manning.com/ibsen/
>
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSS] Rebooting ServiceMix 5
Posted by Claus Ibsen <cl...@gmail.com>.
On Fri, Jul 1, 2011 at 10:13 AM, James Strachan <ja...@fusesource.com> wrote:
> On 29 June 2011 10:14, Geert Schuring <ge...@schuring.eu> wrote:
>> I too have doubts about the Tomcat distribution. The software stack that
>> ServiceMix consists of is already very complex, and contains all kinds of
>> frameworks and components that can be used outside ServiceMix or OSGi as
>> well. In my opinion ServiceMix should focus on providing a consistent, well
>> documented environment instead of trying to serve as much different ways of
>> implementation as possible. I think that's an important reason why the
>> documentation has been so slow and painful for SMX 3 & 4.
>>
>> I think starting new documenation from scratch for SMX 5 is a very good
>> idea. Combined with using scalate and storing the documentation in
>> subversion, we should be able to write version specific and accurate
>> documentation.
>>
>> Would it be possible to drop spring entirely and switch to blueprint for SMX
>> 5? That again would simplify the examples and documentation, and would make
>> SMX 5 more accessible to new users.
>
> An ESB is all about integration; so dropping support for things people
> use is generally bad; though for sure we should recommend on OSGi
> folks use blueprint as its simpler & smaller; though we should still
> support folks using Spring.
>
Yeah Spring is widely used. Its just that spring-dm is ... not their
finest moment.
Maybe that Eclipse Virgo is better (isnt that spring-dm 2.0).
> --
> James
> -------
> FuseSource
> Email: james@fusesource.com
> Web: http://fusesource.com
> Twitter: jstrachan, fusenews
> Blog: http://macstrac.blogspot.com/
>
> Open Source Integration and Messaging
>
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: [DISCUSS] Rebooting ServiceMix 5
Posted by James Strachan <ja...@fusesource.com>.
On 29 June 2011 10:14, Geert Schuring <ge...@schuring.eu> wrote:
> I too have doubts about the Tomcat distribution. The software stack that
> ServiceMix consists of is already very complex, and contains all kinds of
> frameworks and components that can be used outside ServiceMix or OSGi as
> well. In my opinion ServiceMix should focus on providing a consistent, well
> documented environment instead of trying to serve as much different ways of
> implementation as possible. I think that's an important reason why the
> documentation has been so slow and painful for SMX 3 & 4.
>
> I think starting new documenation from scratch for SMX 5 is a very good
> idea. Combined with using scalate and storing the documentation in
> subversion, we should be able to write version specific and accurate
> documentation.
>
> Would it be possible to drop spring entirely and switch to blueprint for SMX
> 5? That again would simplify the examples and documentation, and would make
> SMX 5 more accessible to new users.
An ESB is all about integration; so dropping support for things people
use is generally bad; though for sure we should recommend on OSGi
folks use blueprint as its simpler & smaller; though we should still
support folks using Spring.
--
James
-------
FuseSource
Email: james@fusesource.com
Web: http://fusesource.com
Twitter: jstrachan, fusenews
Blog: http://macstrac.blogspot.com/
Open Source Integration and Messaging
Re: [DISCUSS] Rebooting ServiceMix 5
Posted by Juan José Vázquez Delgado <ju...@gmail.com>.
> Providing a way to easily deploy activiti would definitely be a good thing.
> I don't think it should part of the default distribution, as I'd like
> to keep it as light as possible though.
Ok, it sounds reasonable.
Another point is if you´re going to take into account enabling cloud
features such as multitenancy and horizontal scalability in order to
build iPaaS platforms with SMX 5.
BR,
Juanjo.
Re: [DISCUSS] Rebooting ServiceMix 5
Posted by Guillaume Nodet <gn...@gmail.com>.
Providing a way to easily deploy activiti would definitely be a good thing.
I don't think it should part of the default distribution, as I'd like
to keep it as light as possible though.
On Wed, Jun 29, 2011 at 11:32, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> Hi Geert,
>
> I don't think it's a good idea to remove the Spring support in SMX5 as it's
> fully supported by Camel.
> If an user want to deploy Camel routes defined using Spring DSL, it should.
>
> Of course, we can focus the documentation about the blueprint usage (I think
> it's a good idea), but the Spring support should be still there in SMX5.
>
> Regards
> JB
>
>
> On 06/29/2011 11:14 AM, Geert Schuring wrote:
>>
>> I too have doubts about the Tomcat distribution. The software stack that
>> ServiceMix consists of is already very complex, and contains all kinds of
>> frameworks and components that can be used outside ServiceMix or OSGi asn
>> well. In my opinion ServiceMix should focus on providing a consistent,
>> well
>> documented environment instead of trying to serve as much different ways
>> of
>> implementation as possible. I think that's an important reason why the
>> documentation has been so slow and painful for SMX 3& 4.
>>
>> I think starting new documenation from scratch for SMX 5 is a very good
>> idea. Combined with using scalate and storing the documentation in
>> subversion, we should be able to write version specific and accurate
>> documentation.
>>
>> Would it be possible to drop spring entirely and switch to blueprint for
>> SMX
>> 5? That again would simplify the examples and documentation, and would
>> make
>> SMX 5 more accessible to new users.
>>
>> Geert Schuring.
>>
>> 2011/6/29 Ioannis Canellos<io...@gmail.com>
>>
>>> I am really happy to see the rebooting of Service Mix 5.
>>>
>>> I agree with most of the points mentioned but I am skeptic about the
>>> tomcat
>>> deployment.
>>>
>>> I will skip talking about the advantages of such deployment option, since
>>> I
>>> consider them obvious to all. I am worried on what it will mean to the
>>> pure
>>> OSGi deployments (e.g. restrict the usage of OSGi APIs? Use of a
>>> framework
>>> like pojosr?).
>>>
>>> Any thoughts?
>>>
>>> --
>>> *Ioannis Canellos*
>>> *
>>> http://iocanel.blogspot.com
>>>
>>> Apache Karaf<http://karaf.apache.org/> Committer& PMC
>>> Apache ServiceMix<http://servicemix.apache.org/> Committer
>>> *
>>>
>>>
>>>
>>
>
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSS] Rebooting ServiceMix 5
Posted by Geert Schuring <ge...@schuring.eu>.
JB,
The documentation is my main concern, so if we can somehow agree to only
using blueprint in ServiceMix examples that would be great! The current set
of examples shipped with ServiceMix clearly show that trying to work out
examples without a standard way of packaging and a standard DSL increases
the already steep learning curve significantly. Dropping JBI is already a
great step in that direction.
Geert.
2011/6/29 Jean-Baptiste Onofré <jb...@nanthrax.net>
> Hi Geert,
>
> I don't think it's a good idea to remove the Spring support in SMX5 as it's
> fully supported by Camel.
> If an user want to deploy Camel routes defined using Spring DSL, it should.
>
> Of course, we can focus the documentation about the blueprint usage (I
> think it's a good idea), but the Spring support should be still there in
> SMX5.
>
> Regards
> JB
>
>
>
> On 06/29/2011 11:14 AM, Geert Schuring wrote:
>
>> I too have doubts about the Tomcat distribution. The software stack that
>> ServiceMix consists of is already very complex, and contains all kinds of
>> frameworks and components that can be used outside ServiceMix or OSGi asn
>>
>> well. In my opinion ServiceMix should focus on providing a consistent,
>> well
>> documented environment instead of trying to serve as much different ways
>> of
>> implementation as possible. I think that's an important reason why the
>> documentation has been so slow and painful for SMX 3& 4.
>>
>> I think starting new documenation from scratch for SMX 5 is a very good
>> idea. Combined with using scalate and storing the documentation in
>> subversion, we should be able to write version specific and accurate
>> documentation.
>>
>> Would it be possible to drop spring entirely and switch to blueprint for
>> SMX
>> 5? That again would simplify the examples and documentation, and would
>> make
>> SMX 5 more accessible to new users.
>>
>> Geert Schuring.
>>
>> 2011/6/29 Ioannis Canellos<io...@gmail.com>
>>
>> I am really happy to see the rebooting of Service Mix 5.
>>>
>>> I agree with most of the points mentioned but I am skeptic about the
>>> tomcat
>>> deployment.
>>>
>>> I will skip talking about the advantages of such deployment option, since
>>> I
>>> consider them obvious to all. I am worried on what it will mean to the
>>> pure
>>> OSGi deployments (e.g. restrict the usage of OSGi APIs? Use of a
>>> framework
>>> like pojosr?).
>>>
>>> Any thoughts?
>>>
>>> --
>>> *Ioannis Canellos*
>>> *
>>> http://iocanel.blogspot.com
>>>
>>> Apache Karaf<http://karaf.apache.org/**> Committer& PMC
>>> Apache ServiceMix<http://servicemix.**apache.org/<http://servicemix.apache.org/>>
>>> Committer
>>> *
>>>
>>>
>>>
>>>
>>
>
>
Re: [DISCUSS] Rebooting ServiceMix 5
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Geert,
I don't think it's a good idea to remove the Spring support in SMX5 as
it's fully supported by Camel.
If an user want to deploy Camel routes defined using Spring DSL, it should.
Of course, we can focus the documentation about the blueprint usage (I
think it's a good idea), but the Spring support should be still there in
SMX5.
Regards
JB
On 06/29/2011 11:14 AM, Geert Schuring wrote:
> I too have doubts about the Tomcat distribution. The software stack that
> ServiceMix consists of is already very complex, and contains all kinds of
> frameworks and components that can be used outside ServiceMix or OSGi asn
> well. In my opinion ServiceMix should focus on providing a consistent, well
> documented environment instead of trying to serve as much different ways of
> implementation as possible. I think that's an important reason why the
> documentation has been so slow and painful for SMX 3& 4.
>
> I think starting new documenation from scratch for SMX 5 is a very good
> idea. Combined with using scalate and storing the documentation in
> subversion, we should be able to write version specific and accurate
> documentation.
>
> Would it be possible to drop spring entirely and switch to blueprint for SMX
> 5? That again would simplify the examples and documentation, and would make
> SMX 5 more accessible to new users.
>
> Geert Schuring.
>
> 2011/6/29 Ioannis Canellos<io...@gmail.com>
>
>> I am really happy to see the rebooting of Service Mix 5.
>>
>> I agree with most of the points mentioned but I am skeptic about the tomcat
>> deployment.
>>
>> I will skip talking about the advantages of such deployment option, since I
>> consider them obvious to all. I am worried on what it will mean to the pure
>> OSGi deployments (e.g. restrict the usage of OSGi APIs? Use of a framework
>> like pojosr?).
>>
>> Any thoughts?
>>
>> --
>> *Ioannis Canellos*
>> *
>> http://iocanel.blogspot.com
>>
>> Apache Karaf<http://karaf.apache.org/> Committer& PMC
>> Apache ServiceMix<http://servicemix.apache.org/> Committer
>> *
>>
>>
>>
>
Re: [DISCUSS] Rebooting ServiceMix 5
Posted by Geert Schuring <ge...@schuring.eu>.
I too have doubts about the Tomcat distribution. The software stack that
ServiceMix consists of is already very complex, and contains all kinds of
frameworks and components that can be used outside ServiceMix or OSGi as
well. In my opinion ServiceMix should focus on providing a consistent, well
documented environment instead of trying to serve as much different ways of
implementation as possible. I think that's an important reason why the
documentation has been so slow and painful for SMX 3 & 4.
I think starting new documenation from scratch for SMX 5 is a very good
idea. Combined with using scalate and storing the documentation in
subversion, we should be able to write version specific and accurate
documentation.
Would it be possible to drop spring entirely and switch to blueprint for SMX
5? That again would simplify the examples and documentation, and would make
SMX 5 more accessible to new users.
Geert Schuring.
2011/6/29 Ioannis Canellos <io...@gmail.com>
> I am really happy to see the rebooting of Service Mix 5.
>
> I agree with most of the points mentioned but I am skeptic about the tomcat
> deployment.
>
> I will skip talking about the advantages of such deployment option, since I
> consider them obvious to all. I am worried on what it will mean to the pure
> OSGi deployments (e.g. restrict the usage of OSGi APIs? Use of a framework
> like pojosr?).
>
> Any thoughts?
>
> --
> *Ioannis Canellos*
> *
> http://iocanel.blogspot.com
>
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> Apache ServiceMix <http://servicemix.apache.org/> Committer
> *
>
>
>
Re: [DISCUSS] Rebooting ServiceMix 5
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
I'm agree with Guillaume.
It's clear that Karaf is the premium container and most of the people
will certainly use it.
But there are some people which have:
1/ existing IT policies and hardware. For instance, in financial
companies, they have some kind of "print" to use only this kind of
application server (WebSphere, WebLogic, JBoss, etc).
2/ an ESB is never alone: a company would like to use an ESB in an
existing ecosystem. It means that applications are already in place and
the ESB has to use it. It means that some resources could be shared (for
instance, a transaction manager).
I'm afraid that without providing a WAR (which can be deployed in a JEE
server), we won't be able to address really enterprise users.
More over, from a technical perspective, as Guillaume said, it's better
to keep things unrelated to OSGi. OSGi specific components should be
clearly identify.
Regards
JB
On 06/29/2011 03:50 PM, Guillaume Nodet wrote:
> What I really mean when talking about a Tomcat based deployement is
> really to bring the value we'll work on (i.e. message analysis,
> auditing, console and such) which are completely unrelated to OSGi, to
> people that want to deploy camel routes using web apps in Tomcat. If
> you look at the Camel survey
> (http://camel.apache.org/camel-30-roadmap.data/camel-survey-2010.pdf)
> a lot of Camel users don't really use OSGi, and there's no reason why
> not trying to help those people when using Camel to build an ESB.
>
> I'm not sure how it can be done technically, and I don't really want
> to focus on this area specifically, but if it can be done without too
> much pain, I think it would help. That said, I think Gert's points
> are fully in line with my mindset in which Karaf is a much better
> container, but not everybody is ready to pay the initial cost of
> learning OSGi.
>
> On Wed, Jun 29, 2011 at 10:45, Ioannis Canellos<io...@gmail.com> wrote:
>> I am really happy to see the rebooting of Service Mix 5.
>>
>> I agree with most of the points mentioned but I am skeptic about the tomcat
>> deployment.
>>
>> I will skip talking about the advantages of such deployment option, since I
>> consider them obvious to all. I am worried on what it will mean to the pure
>> OSGi deployments (e.g. restrict the usage of OSGi APIs? Use of a framework
>> like pojosr?).
>>
>> Any thoughts?
>>
>> --
>> *Ioannis Canellos*
>> *
>> http://iocanel.blogspot.com
>>
>> Apache Karaf<http://karaf.apache.org/> Committer& PMC
>> Apache ServiceMix<http://servicemix.apache.org/> Committer
>> *
>>
>
>
>
Re: [DISCUSS] Rebooting ServiceMix 5
Posted by Guillaume Nodet <gn...@gmail.com>.
What I really mean when talking about a Tomcat based deployement is
really to bring the value we'll work on (i.e. message analysis,
auditing, console and such) which are completely unrelated to OSGi, to
people that want to deploy camel routes using web apps in Tomcat. If
you look at the Camel survey
(http://camel.apache.org/camel-30-roadmap.data/camel-survey-2010.pdf)
a lot of Camel users don't really use OSGi, and there's no reason why
not trying to help those people when using Camel to build an ESB.
I'm not sure how it can be done technically, and I don't really want
to focus on this area specifically, but if it can be done without too
much pain, I think it would help. That said, I think Gert's points
are fully in line with my mindset in which Karaf is a much better
container, but not everybody is ready to pay the initial cost of
learning OSGi.
On Wed, Jun 29, 2011 at 10:45, Ioannis Canellos <io...@gmail.com> wrote:
> I am really happy to see the rebooting of Service Mix 5.
>
> I agree with most of the points mentioned but I am skeptic about the tomcat
> deployment.
>
> I will skip talking about the advantages of such deployment option, since I
> consider them obvious to all. I am worried on what it will mean to the pure
> OSGi deployments (e.g. restrict the usage of OSGi APIs? Use of a framework
> like pojosr?).
>
> Any thoughts?
>
> --
> *Ioannis Canellos*
> *
> http://iocanel.blogspot.com
>
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> Apache ServiceMix <http://servicemix.apache.org/> Committer
> *
>
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSS] Rebooting ServiceMix 5
Posted by James Strachan <ja...@fusesource.com>.
On 29 June 2011 09:45, Ioannis Canellos <io...@gmail.com> wrote:
> I am really happy to see the rebooting of Service Mix 5.
>
> I agree with most of the points mentioned but I am skeptic about the tomcat
> deployment.
I hear you :)
In many ways I see the Tomcat approach (TomMix? CatMix? ServiCat? :)
as quite similar to the TomEE initiative adding JEE capability to
Tomcat - we should definitely share approaches & maybe code...
http://openejb.apache.org/3.0/apache-tomee.html
Many developers & operations folks are very happy with Tomcat already
& have tons of WARs that are heavily tested & in production in Tomcat.
Its a trade off; on the plus side OSGi is amazingly powerful & dynamic
& asynchronous and very loosely coupled at the class loader level. On
the downside it adds significant complexity to application developers
compared to WARs (especially when legacy code is used, there's a lot
of code out there that either doesn't work or is difficult to use in
OSGi and its so easy to trip yourself up compared to the relatively
simple flat class loaders in WARs) and there is a migration cost to
moving from Tomcat to something else.
Folks should be able to choose which side of these trade offs they
want to sit; very powerful, dynamic & lots of complex class loader
magic (with a cost) versus simple (but less dynamic & less class
loader sharing). From an application developers perspective
(especially those who are new to ServiceMix) the Tomcat approach
offers huge benefits - as it looks & behaves exactly like Tomcat which
most developers already know & avoids folks having to go through the
OSGi learning curve + OSGi metadata pain.
Irrespective of their decision on Tomcat v OSGi, folks should still be
able to benefit from all the goodness that ServiceMIx can bring!
>From an implementation perspective I see the Tomcat approach for
ServiceMix being a fairly static container like TomEE; it boots up
with the shared ServiceMix goodness on the shared class loader; you
then just deploy WARs. To change things you install/uninstall things
into Tomcat and restart; so much simpler & more static - but still
very useful.
--
James
-------
FuseSource
Email: james@fusesource.com
Web: http://fusesource.com
Twitter: jstrachan, fusenews
Blog: http://macstrac.blogspot.com/
Open Source Integration and Messaging
Re: [DISCUSS] Rebooting ServiceMix 5
Posted by Lars Heinemann <lh...@apache.org>.
Hi Ioannis,
deployment to Tomcat is just an option and meant for easy starting to work with SMX.
I think the Karaf based distro will remain the main distro.
Best regards,
Lars
--------------------------------------
Lars Heinemann
FuseSource
Email: lhein@fusesource.com
Web: http://www.fusesource.com
Blog: http://lhein.blogspot.com
Twitter: lhein77
Am 29.06.2011 um 10:45 schrieb Ioannis Canellos:
> I am really happy to see the rebooting of Service Mix 5.
>
> I agree with most of the points mentioned but I am skeptic about the tomcat
> deployment.
>
> I will skip talking about the advantages of such deployment option, since I
> consider them obvious to all. I am worried on what it will mean to the pure
> OSGi deployments (e.g. restrict the usage of OSGi APIs? Use of a framework
> like pojosr?).
>
> Any thoughts?
>
> --
> *Ioannis Canellos*
> *
> http://iocanel.blogspot.com
>
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> Apache ServiceMix <http://servicemix.apache.org/> Committer
> *
Re: [DISCUSS] Rebooting ServiceMix 5
Posted by Michael Van <mv...@comcast.net>.
After a re-read, I agree with your design goals. Me gusta!
+1
Guillaume Nodet wrote:
>
> I guess you missed in my first email one important fact. To build the
> added value I've been talking about, we don't really need the NMR
> imho. I'm convinced we can do it directly on top of camel without the
> need for another layer, mostly using Camel interceptors. That way,
> OSGi is not really needed anymore, though it's still the best way to
> deploy Camel routes using Karaf and would remain the main and
> standlone ServiceMix distribution.
>
> On Fri, Jul 1, 2011 at 22:12, Michael Van <mvangeertruy@comcast.net>
> wrote:
>> JB,
>>
>> Thats an excellent goal. If it works, I can see the nmr component being
>> something provided by many major J2EE vendors out-of-the-box to thier
>> users.
>>
>>
>> Jean-Baptiste Onofré wrote:
>>>
>>> Hi all,
>>>
>>> I'm not agree with that, and I don't think that it's the Guillaume's
>>> point of view.
>>>
>>> The idea speaking about Tomcat is not to create ServiceCat or something
>>> like that. If the purpose was this one, Karaf + Jetty already does the
>>> stuff.
>>>
>>> The idea is more to provide:
>>> - ServiceMix as a standalone ESB (as ServiceMix 4) powered by Karaf
>>> container
>>> - ServiceMix as an embeddable WAR or EAR. Tomcat is just an example but
>>> the purpose is wider. For my point of view, if we want to go this way,
>>> we shouldn't be focus on Tomcat but be more generic. The purpose is to
>>> be able to deploy ServiceMix 5 into existing containers like Tomcat, but
>>> also Glassfish, Websphere, etc. The goals are to use the container
>>> resources (JNDI, JTA, etc integration) and increase the ServiceMix
>>> adoption for existing IT administrators.
>>>
>>> Regards
>>> JB
>>>
>>> On 07/01/2011 09:03 PM, Michael Van wrote:
>>>> Upon re-reading this thread, it appears there are two subtely different
>>>> approaches being suggested:
>>>> 1) To merge most of SMX into the Tomcat container creating a new
>>>> little
>>>> beasty "Servicecat" or something, and
>>>> 2) To modify the existing SMX bundles so that they work inside of a
>>>> (any)
>>>> servlet container.
>>>>
>>>> I like the second option more than the first, because it will greatly
>>>> increase the set of users that can/will-be-able-to use it. The first
>>>> option
>>>> is intriguing, but I dont' know if it would overcome the stated design
>>>> goal
>>>> of allowing folks who are using legacy environements to use SMX.
>>>>
>>>> Could someone clarify the option being proposed?
>>>>
>>>>
>>>> dblevins wrote:
>>>>>
>>>>>
>>>>> 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.
>>>>>>
>>>>>
>>>>> Maybe two years ago Tuscany got inspired to do the same with Tomcat
>>>>> and
>>>>> also pointed at what we now call TomEE. They basically took all the
>>>>> Tomcat integration code, said thank you, and went their separate way
>>>>> with
>>>>> it. I admit it was a little disappointing as we would have happily
>>>>> supported them and it would have been great to see the idea grow
>>>>> rather
>>>>> than be copied. It's been forked again recently for a commercial app
>>>>> server. Similar thanks and see you later.
>>>>>
>>>>> We're more than happy to support ServiceMix if you guys want to go
>>>>> down
>>>>> this route. The backup plan could of course be to take the code and
>>>>> run,
>>>>> but it would be great to at least give working together a shot.
>>>>>
>>>>>
>>>>> -David
>>>>>
>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://servicemix.396122.n5.nabble.com/DISCUSS-Rebooting-ServiceMix-5-tp4528896p4543013.html
>>>> Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
>>>
>>
>>
>> --
>> View this message in context:
>> http://servicemix.396122.n5.nabble.com/DISCUSS-Rebooting-ServiceMix-5-tp4528896p4543186.html
>> Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
>>
>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
--
View this message in context: http://servicemix.396122.n5.nabble.com/DISCUSS-Rebooting-ServiceMix-5-tp4528896p4544053.html
Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Re: [DISCUSS] Rebooting ServiceMix 5
Posted by Kurt Westerfeld <ku...@gmail.com>.
On Fri, Jul 1, 2011 at 4:28 PM, Guillaume Nodet <gn...@gmail.com> wrote:
> I guess you missed in my first email one important fact. To build the
> added value I've been talking about, we don't really need the NMR
> imho. I'm convinced we can do it directly on top of camel without the
> need for another layer, mostly using Camel interceptors. That way,
> OSGi is not really needed anymore, though it's still the best way to
> deploy Camel routes using Karaf and would remain the main and
> standlone ServiceMix distribution.
>
>
I have read this thread regarding rebooting SMX and departure from the NMR,
and I've wondered if my experience with SMX 4 would help the discussion. I
think this may come across as a "dissenting opinion" on this proposal, but
please know that I am a HUGE SMX fan and am forwarding these opinions in the
best possible way I know how.
My experience with SMX has been 100% positive. In the business area I
worked
with SMX, and previously OpenESB, the use-case was much less
messaging-oriented
and more orchestration-oriented. Thus, we relied heavily on Apache ODE. It
turns
out, that Apache ODE is really good for one thing, and perhaps if Apache
Camel did
this one thing well+hassle-free, we would have used it and my experiences
would
have been different.
My worry with the proposal for SMX 5 and it's Camel-centricity is that I
have had
a great experience with SMX but I have never used Camel. We just didn't
need
what it had to offer.
The architecture looked like this:
- inbound requests secured with WS-Security. We used CXF binding
components
with a lot of Spring-DM configuration to allow externalized
configuration.
Really happy with all that.
- outbound external requests were also CXF, although we'd have a mixture
of authorization models where some components were using basic auth,
others
soap with custom auth, etc.
- some requests were directly routed to Java services if they were
small and synchronous-oriented (ie. call/response). We used cxf SE for
this.
- we used cxf proxy constructs to call from java to anything else. This
worked
well as we prototyped a bunch of stuff at times in java, and then when
we
needed asynchronous, long-running behavior, we moved those prototypes to
ODE.
- because everything was talking over the NMR, we could add intereceptors
to
the bus and monitor everything. We even had a policy-based audit
function
over the NMR that was very clever.
- we created a visualization mechanism for understanding the wires over
the NMR,
with an Apache Felix plugin. Alas, while I wanted to contribute that
work
back to the community, it can't happen now.
- "The main work" of the project was to orchestrate long running
processes.
Involved in this orchestration was wait-states for human interactions,
such
as approvals, escalations, remediations, etc. Apache ODE was a good
choice
here, because a persistent BPEL process instance that lands in a <pick>
construct has some nice qualities (ie. resilient to server restart).
Our
main process could have 10 or so steps in it, each one which may take
anywhere from seconds to days to run. All of these steps talked to
external
systems.
- a significant effort was involved in creating a normalization of
identity
concerns over the bus. I think in retrospect much of our work would
have
been alleviated had we taken the approach to patch certain components
instead
of relying on message exchange interceptors to do things "the hard
way".
Nevertheless, it's important to note that SMX provides an avenue for
dealing
with identity concerns, but doesn't quite get things right. Even so,
having
CXF and NMR sources around help you a lot, and you can glue things
together
with interceptors. I submitted a few patches here and there to ODE and
CXF
component (SE proxy, for example) that propate subject/identity
materials
better and I think it's getting there.
In all, I'd say the solution component demographic was as follows:
10% CXF, File, Quartz, non-Java components (ie. Spring-DM config)
20% Apache ODE
70% Java components (transformations, logic, policy-based routing, some
karaf commands, etc.)
Now, about the Java components, sure some of it could be message
transformation.
But the issue with that is that when you need to have mid-level programmer
talent
join a project, start contributing right away, and have no ESB background,
writing
something in Java many times is the right choice, simply because of the
debugger
support. To me, tooling is a much bigger issue than maybe the SMX and Camel
community realize. Writing a camel route would be applicable in some cases,
but
probably only 30% of this overall solution would fall in this category.
The main orchestration processes being done with Camel have some merit. I
think
this would be interesting, in that if Camel had a persistent equivalent to
BPEL
"<pick>", with message correlation, fault tolerance/resliency to system
restart,
that worked hassle-free and without too much assembly, it would be really
useful.
In talkingto James this I believe this is possible, but it's not obvious to
me how,
so it is really academic at this point.
I am no longer involved in this solution, so I'm not trying to entertain
"how would
I do all this in SMX 5 with Camel only?". What I'm trying to do is
highlight a
different, completely positive use case with SMX that doesn't involve Camel.
On
paper, I really like Camel but I haven't had any deep involvement with a
project
using it, so I just haven't formed an opinion on it--I'm positive but not
informed
I guess. In a world where the NMR goes away and Camel is at the forefront,
I'm
not sure this use-case would have been obvious and we may have not
considered
SMX at all, which would have been a shame.
As an aside, the positive reaction I had to all of this was experienced
while
learning OSGi, Karaf, etc., which was a steep curve, because we ended up
having to
create a fair number of bundles ourselves for libraries that SMX didn't
provide. That
being said, to me the SMX bundle repo is a HUGE salvation and should be
perhaps
spun off from SMX and made an Apache project of its own, similar to the
older
Spring Enterprise Bundle Repository (call it Apache EBR). Since Apache
maintains
so much build infrastructure and maven repos anyway, it would make sense to
have
the "bundlization" happen from an Apache project. I would think that as
projects
want to peel off the work from the Apache EBR, they should have a way to
manage
removing their components from the EBR and stamp their project as "OSGi
Ready".
Just a thought.
Hope this helps all and good luck,
Kurt
Re: [DISCUSS] Rebooting ServiceMix 5
Posted by Guillaume Nodet <gn...@gmail.com>.
I guess you missed in my first email one important fact. To build the
added value I've been talking about, we don't really need the NMR
imho. I'm convinced we can do it directly on top of camel without the
need for another layer, mostly using Camel interceptors. That way,
OSGi is not really needed anymore, though it's still the best way to
deploy Camel routes using Karaf and would remain the main and
standlone ServiceMix distribution.
On Fri, Jul 1, 2011 at 22:12, Michael Van <mv...@comcast.net> wrote:
> JB,
>
> Thats an excellent goal. If it works, I can see the nmr component being
> something provided by many major J2EE vendors out-of-the-box to thier users.
>
>
> Jean-Baptiste Onofré wrote:
>>
>> Hi all,
>>
>> I'm not agree with that, and I don't think that it's the Guillaume's
>> point of view.
>>
>> The idea speaking about Tomcat is not to create ServiceCat or something
>> like that. If the purpose was this one, Karaf + Jetty already does the
>> stuff.
>>
>> The idea is more to provide:
>> - ServiceMix as a standalone ESB (as ServiceMix 4) powered by Karaf
>> container
>> - ServiceMix as an embeddable WAR or EAR. Tomcat is just an example but
>> the purpose is wider. For my point of view, if we want to go this way,
>> we shouldn't be focus on Tomcat but be more generic. The purpose is to
>> be able to deploy ServiceMix 5 into existing containers like Tomcat, but
>> also Glassfish, Websphere, etc. The goals are to use the container
>> resources (JNDI, JTA, etc integration) and increase the ServiceMix
>> adoption for existing IT administrators.
>>
>> Regards
>> JB
>>
>> On 07/01/2011 09:03 PM, Michael Van wrote:
>>> Upon re-reading this thread, it appears there are two subtely different
>>> approaches being suggested:
>>> 1) To merge most of SMX into the Tomcat container creating a new little
>>> beasty "Servicecat" or something, and
>>> 2) To modify the existing SMX bundles so that they work inside of a
>>> (any)
>>> servlet container.
>>>
>>> I like the second option more than the first, because it will greatly
>>> increase the set of users that can/will-be-able-to use it. The first
>>> option
>>> is intriguing, but I dont' know if it would overcome the stated design
>>> goal
>>> of allowing folks who are using legacy environements to use SMX.
>>>
>>> Could someone clarify the option being proposed?
>>>
>>>
>>> dblevins wrote:
>>>>
>>>>
>>>> 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.
>>>>>
>>>>
>>>> Maybe two years ago Tuscany got inspired to do the same with Tomcat and
>>>> also pointed at what we now call TomEE. They basically took all the
>>>> Tomcat integration code, said thank you, and went their separate way
>>>> with
>>>> it. I admit it was a little disappointing as we would have happily
>>>> supported them and it would have been great to see the idea grow rather
>>>> than be copied. It's been forked again recently for a commercial app
>>>> server. Similar thanks and see you later.
>>>>
>>>> We're more than happy to support ServiceMix if you guys want to go down
>>>> this route. The backup plan could of course be to take the code and
>>>> run,
>>>> but it would be great to at least give working together a shot.
>>>>
>>>>
>>>> -David
>>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://servicemix.396122.n5.nabble.com/DISCUSS-Rebooting-ServiceMix-5-tp4528896p4543013.html
>>> Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
>>
>
>
> --
> View this message in context: http://servicemix.396122.n5.nabble.com/DISCUSS-Rebooting-ServiceMix-5-tp4528896p4543186.html
> Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
>
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSS] Rebooting ServiceMix 5
Posted by Michael Van <mv...@comcast.net>.
JB,
Thats an excellent goal. If it works, I can see the nmr component being
something provided by many major J2EE vendors out-of-the-box to thier users.
Jean-Baptiste Onofré wrote:
>
> Hi all,
>
> I'm not agree with that, and I don't think that it's the Guillaume's
> point of view.
>
> The idea speaking about Tomcat is not to create ServiceCat or something
> like that. If the purpose was this one, Karaf + Jetty already does the
> stuff.
>
> The idea is more to provide:
> - ServiceMix as a standalone ESB (as ServiceMix 4) powered by Karaf
> container
> - ServiceMix as an embeddable WAR or EAR. Tomcat is just an example but
> the purpose is wider. For my point of view, if we want to go this way,
> we shouldn't be focus on Tomcat but be more generic. The purpose is to
> be able to deploy ServiceMix 5 into existing containers like Tomcat, but
> also Glassfish, Websphere, etc. The goals are to use the container
> resources (JNDI, JTA, etc integration) and increase the ServiceMix
> adoption for existing IT administrators.
>
> Regards
> JB
>
> On 07/01/2011 09:03 PM, Michael Van wrote:
>> Upon re-reading this thread, it appears there are two subtely different
>> approaches being suggested:
>> 1) To merge most of SMX into the Tomcat container creating a new little
>> beasty "Servicecat" or something, and
>> 2) To modify the existing SMX bundles so that they work inside of a
>> (any)
>> servlet container.
>>
>> I like the second option more than the first, because it will greatly
>> increase the set of users that can/will-be-able-to use it. The first
>> option
>> is intriguing, but I dont' know if it would overcome the stated design
>> goal
>> of allowing folks who are using legacy environements to use SMX.
>>
>> Could someone clarify the option being proposed?
>>
>>
>> dblevins wrote:
>>>
>>>
>>> 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.
>>>>
>>>
>>> Maybe two years ago Tuscany got inspired to do the same with Tomcat and
>>> also pointed at what we now call TomEE. They basically took all the
>>> Tomcat integration code, said thank you, and went their separate way
>>> with
>>> it. I admit it was a little disappointing as we would have happily
>>> supported them and it would have been great to see the idea grow rather
>>> than be copied. It's been forked again recently for a commercial app
>>> server. Similar thanks and see you later.
>>>
>>> We're more than happy to support ServiceMix if you guys want to go down
>>> this route. The backup plan could of course be to take the code and
>>> run,
>>> but it would be great to at least give working together a shot.
>>>
>>>
>>> -David
>>>
>>
>>
>> --
>> View this message in context:
>> http://servicemix.396122.n5.nabble.com/DISCUSS-Rebooting-ServiceMix-5-tp4528896p4543013.html
>> Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
>
--
View this message in context: http://servicemix.396122.n5.nabble.com/DISCUSS-Rebooting-ServiceMix-5-tp4528896p4543186.html
Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Re: [DISCUSS] Rebooting ServiceMix 5
Posted by David Blevins <da...@gmail.com>.
On Fri, Jul 1, 2011 at 1:01 PM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> - ServiceMix as an embeddable WAR or EAR. Tomcat is just an example but the
> purpose is wider. For my point of view, if we want to go this way, we
> shouldn't be focus on Tomcat but be more generic. The purpose is to be able
> to deploy ServiceMix 5 into existing containers like Tomcat, but also
> Glassfish, Websphere, etc. The goals are to use the container resources
> (JNDI, JTA, etc integration) and increase the ServiceMix adoption for
> existing IT administrators.
Along those lines there are certainly some very interesting options.
The industry really hasn't realized it yet and has only started to get
it's head around some of the new tech, but basically the entire
deployment model of Java EE got busted wide open.
If you drop a META-INF/services/javax.enterprise.inject.spi.Extension
file into a jar that is put into a WAR or EAR, you can quite literally
participate in deployment and extend the app. And it's standard and
usable in any server that supports CDI -- which is all certified Java
EE 6 full or web profile servers.
Users could write apps that have @Inject MyServiceMixThingy, and you
could provide that standardly with all the existing hooks. You can
even add new components, or even add your own dependency injection
annotations or wrap the startup and shutdown of each and every
component in the app. Frankly it's a little mind boggling.
-David
Re: [DISCUSS] Rebooting ServiceMix 5
Posted by James Strachan <ja...@fusesource.com>.
Getting low level implementation detail focussed for a second I'd say
we could do all of these things...
i) make all the ServiceMix goodness available as bundles/jars that
folks can use on any classpath or OSGi container (pretty much what we
do already really - though we maybe need a couple of tweaks to work
easier outside of OSGi maybe - or PojoSR maybe - or maybe something a
little lighter when outside of OSGi?)
ii) provide a Karaf distro with all the ServiceMix goodness in there;
preferably light weight with some stuff optional features to keep
things small & light (e.g. making NMR/JBI an optional feature etc) -
(again kinda what we do already just maybe doing a smaller lighter
version for 5)
iii) provide a WAR using ServiceMix with some permutation of ActiveMQ
/ Camel / CXF / ... etc - or make it easy, say via maven WAR overlays,
for folks to bind ServiceMix goodness into their WARs
iv) provide a Tomcat distro with ServiceMix inside - a ServiCat /
TomMix thingy; where servicemix goodness is available on the shared
class loader (with maybe a separate WAR for the web console or
something) so that if any WAR is deployed with some ActiveMQ / Camel /
CXF / ... etc stuff inside, the ServiceMix stuff can do its thing;
without every WAR having to include a full ServiceMix distro inside
it.
Option iii) is pretty easy and would work in any Servlet engine today
- assuming we do (i) so that the ServiceMix goodness can work on a
simple flat class loader (e.g. PojoSR today - or maybe something a
little lighter if OSGi isn't a requirement); the downside is it means
including all the same stuff in each WAR.
Whereas (iv) would be specific to the ServiceMix Tomcat distro
(possibly based on TomEE?) but would allow hopefully any WAR using
ActiveMQ / Camel / CXF / ... to just work with the ServiceMix
goodness. For folks using multiple WARs and ServiceMix goodness option
(iv) would be the lightest option, at the cost of a custom Tomcat
distro.
Incidentally maybe one day the TomEE extension mechanisms could become
part of the standard Tomcat distro; then its really we'd have 'Tomcat
extensions' for EE / ServiceMix; then folks could take a vanilla
Tomcat distro and use the Tomcat extensions mechanism to install EE
(OpenEJB) or ServiceMix? (Without grokking TomEE the previous sentence
probably wont' make much sense but don't worry about that, it might
take a long time to get there anyway...).
On 1 July 2011 21:01, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> Hi all,
>
> I'm not agree with that, and I don't think that it's the Guillaume's point
> of view.
>
> The idea speaking about Tomcat is not to create ServiceCat or something like
> that. If the purpose was this one, Karaf + Jetty already does the stuff.
>
> The idea is more to provide:
> - ServiceMix as a standalone ESB (as ServiceMix 4) powered by Karaf
> container
> - ServiceMix as an embeddable WAR or EAR. Tomcat is just an example but the
> purpose is wider. For my point of view, if we want to go this way, we
> shouldn't be focus on Tomcat but be more generic. The purpose is to be able
> to deploy ServiceMix 5 into existing containers like Tomcat, but also
> Glassfish, Websphere, etc. The goals are to use the container resources
> (JNDI, JTA, etc integration) and increase the ServiceMix adoption for
> existing IT administrators.
>
> Regards
> JB
>
> On 07/01/2011 09:03 PM, Michael Van wrote:
>>
>> Upon re-reading this thread, it appears there are two subtely different
>> approaches being suggested:
>> 1) To merge most of SMX into the Tomcat container creating a new little
>> beasty "Servicecat" or something, and
>> 2) To modify the existing SMX bundles so that they work inside of a (any)
>> servlet container.
>>
>> I like the second option more than the first, because it will greatly
>> increase the set of users that can/will-be-able-to use it. The first
>> option
>> is intriguing, but I dont' know if it would overcome the stated design
>> goal
>> of allowing folks who are using legacy environements to use SMX.
>>
>> Could someone clarify the option being proposed?
>>
>>
>> dblevins wrote:
>>>
>>>
>>> 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.
>>>>
>>>
>>> Maybe two years ago Tuscany got inspired to do the same with Tomcat and
>>> also pointed at what we now call TomEE. They basically took all the
>>> Tomcat integration code, said thank you, and went their separate way with
>>> it. I admit it was a little disappointing as we would have happily
>>> supported them and it would have been great to see the idea grow rather
>>> than be copied. It's been forked again recently for a commercial app
>>> server. Similar thanks and see you later.
>>>
>>> We're more than happy to support ServiceMix if you guys want to go down
>>> this route. The backup plan could of course be to take the code and run,
>>> but it would be great to at least give working together a shot.
>>>
>>>
>>> -David
>>>
>>
>>
>> --
>> View this message in context:
>> http://servicemix.396122.n5.nabble.com/DISCUSS-Rebooting-ServiceMix-5-tp4528896p4543013.html
>> Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
>
--
James
-------
FuseSource
Email: james@fusesource.com
Web: http://fusesource.com
Twitter: jstrachan, fusenews
Blog: http://macstrac.blogspot.com/
Open Source Integration and Messaging
Re: [DISCUSS] Rebooting ServiceMix 5
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi all,
I'm not agree with that, and I don't think that it's the Guillaume's
point of view.
The idea speaking about Tomcat is not to create ServiceCat or something
like that. If the purpose was this one, Karaf + Jetty already does the
stuff.
The idea is more to provide:
- ServiceMix as a standalone ESB (as ServiceMix 4) powered by Karaf
container
- ServiceMix as an embeddable WAR or EAR. Tomcat is just an example but
the purpose is wider. For my point of view, if we want to go this way,
we shouldn't be focus on Tomcat but be more generic. The purpose is to
be able to deploy ServiceMix 5 into existing containers like Tomcat, but
also Glassfish, Websphere, etc. The goals are to use the container
resources (JNDI, JTA, etc integration) and increase the ServiceMix
adoption for existing IT administrators.
Regards
JB
On 07/01/2011 09:03 PM, Michael Van wrote:
> Upon re-reading this thread, it appears there are two subtely different
> approaches being suggested:
> 1) To merge most of SMX into the Tomcat container creating a new little
> beasty "Servicecat" or something, and
> 2) To modify the existing SMX bundles so that they work inside of a (any)
> servlet container.
>
> I like the second option more than the first, because it will greatly
> increase the set of users that can/will-be-able-to use it. The first option
> is intriguing, but I dont' know if it would overcome the stated design goal
> of allowing folks who are using legacy environements to use SMX.
>
> Could someone clarify the option being proposed?
>
>
> dblevins wrote:
>>
>>
>> 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.
>>>
>>
>> Maybe two years ago Tuscany got inspired to do the same with Tomcat and
>> also pointed at what we now call TomEE. They basically took all the
>> Tomcat integration code, said thank you, and went their separate way with
>> it. I admit it was a little disappointing as we would have happily
>> supported them and it would have been great to see the idea grow rather
>> than be copied. It's been forked again recently for a commercial app
>> server. Similar thanks and see you later.
>>
>> We're more than happy to support ServiceMix if you guys want to go down
>> this route. The backup plan could of course be to take the code and run,
>> but it would be great to at least give working together a shot.
>>
>>
>> -David
>>
>
>
> --
> View this message in context: http://servicemix.396122.n5.nabble.com/DISCUSS-Rebooting-ServiceMix-5-tp4528896p4543013.html
> Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Re: [DISCUSS] Rebooting ServiceMix 5
Posted by Michael Van <mv...@comcast.net>.
Upon re-reading this thread, it appears there are two subtely different
approaches being suggested:
1) To merge most of SMX into the Tomcat container creating a new little
beasty "Servicecat" or something, and
2) To modify the existing SMX bundles so that they work inside of a (any)
servlet container.
I like the second option more than the first, because it will greatly
increase the set of users that can/will-be-able-to use it. The first option
is intriguing, but I dont' know if it would overcome the stated design goal
of allowing folks who are using legacy environements to use SMX.
Could someone clarify the option being proposed?
dblevins wrote:
>
>
> 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.
>>
>
> Maybe two years ago Tuscany got inspired to do the same with Tomcat and
> also pointed at what we now call TomEE. They basically took all the
> Tomcat integration code, said thank you, and went their separate way with
> it. I admit it was a little disappointing as we would have happily
> supported them and it would have been great to see the idea grow rather
> than be copied. It's been forked again recently for a commercial app
> server. Similar thanks and see you later.
>
> We're more than happy to support ServiceMix if you guys want to go down
> this route. The backup plan could of course be to take the code and run,
> but it would be great to at least give working together a shot.
>
>
> -David
>
--
View this message in context: http://servicemix.396122.n5.nabble.com/DISCUSS-Rebooting-ServiceMix-5-tp4528896p4543013.html
Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Re: [DISCUSS] Rebooting ServiceMix 5
Posted by James Strachan <ja...@fusesource.com>.
On 1 July 2011 15:59, Michael Van <mv...@comcast.net> 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?
I guess if folks just used the scala / scalaz DSLs for writing routes
in camel, it'd feel like its a Scala ESB :). Maybe ServiceMix needs
its own Scala DSLs too...
--
James
-------
FuseSource
Email: james@fusesource.com
Web: http://fusesource.com
Twitter: jstrachan, fusenews
Blog: http://macstrac.blogspot.com/
Open Source Integration and Messaging
Re: [DISCUSS] Rebooting ServiceMix 5
Posted by James Strachan <ja...@fusesource.com>.
On Friday, 1 July 2011, dblevins <da...@gmail.com> wrote:
>
> 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.
>>
>
> Maybe two years ago Tuscany got inspired to do the same with Tomcat and also
> pointed at what we now call TomEE. They basically took all the Tomcat
> integration code, said thank you, and went their separate way with it. I
> admit it was a little disappointing as we would have happily supported them
> and it would have been great to see the idea grow rather than be copied.
> It's been forked again recently for a commercial app server. Similar thanks
> and see you later.
>
> We're more than happy to support ServiceMix if you guys want to go down this
> route. The backup plan could of course be to take the code and run, but it
> would be great to at least give working together a shot.
I'd hope we can share code. I can see folks wanting to mix JEE stuff
and ServiceMix stuff inside the same Tomcat server
--
James
-------
FuseSource
Email: james@fusesource.com
Web: http://fusesource.com
Twitter: jstrachan, fusenews
Blog: http://macstrac.blogspot.com/
Open Source Integration and Messaging
Re: [DISCUSS] Rebooting ServiceMix 5
Posted by dblevins <da...@gmail.com>.
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.
>
Maybe two years ago Tuscany got inspired to do the same with Tomcat and also
pointed at what we now call TomEE. They basically took all the Tomcat
integration code, said thank you, and went their separate way with it. I
admit it was a little disappointing as we would have happily supported them
and it would have been great to see the idea grow rather than be copied.
It's been forked again recently for a commercial app server. Similar thanks
and see you later.
We're more than happy to support ServiceMix if you guys want to go down this
route. The backup plan could of course be to take the code and run, but it
would be great to at least give working together a shot.
-David
--
View this message in context: http://servicemix.396122.n5.nabble.com/DISCUSS-Rebooting-ServiceMix-5-tp4528896p4542986.html
Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Re: [DISCUSS] Rebooting ServiceMix 5
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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<mvangeertruy@comcast.net> 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: james@fusesource.com
>> 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.
Re: [DISCUSS] Rebooting ServiceMix 5
Posted by Michael Van <mv...@comcast.net>.
>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 <mvangeertruy@comcast.net> 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: james@fusesource.com
> 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.
Re: [DISCUSS] Rebooting ServiceMix 5
Posted by James Strachan <ja...@fusesource.com>.
On 1 July 2011 15:32, Michael Van <mv...@comcast.net> 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: james@fusesource.com
Web: http://fusesource.com
Twitter: jstrachan, fusenews
Blog: http://macstrac.blogspot.com/
Open Source Integration and Messaging
Re: [DISCUSS] Rebooting ServiceMix 5
Posted by Ioannis Canellos <io...@gmail.com>.
On Fri, Jul 1, 2011 at 5:32 PM, Michael Van <mv...@comcast.net>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.
>
I didn't make a point. I just expressed some concerns.
On the contrary, I like the idea of supporting both tomcat and karaf.
--
*Ioannis Canellos*
*
http://iocanel.blogspot.com
Apache Karaf <http://karaf.apache.org/> Committer & PMC
Apache ServiceMix <http://servicemix.apache.org/> Committer
*
Re: [DISCUSS] Rebooting ServiceMix 5
Posted by Michael Van <mv...@comcast.net>.
+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. 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.
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!
iocanel wrote:
>
> I am really happy to see the rebooting of Service Mix 5.
>
> I agree with most of the points mentioned but I am skeptic about the
> tomcat
> deployment.
>
> I will skip talking about the advantages of such deployment option, since
> I
> consider them obvious to all. I am worried on what it will mean to the
> pure
> OSGi deployments (e.g. restrict the usage of OSGi APIs? Use of a framework
> like pojosr?).
>
> Any thoughts?
>
> --
> *Ioannis Canellos*
> *
> http://iocanel.blogspot.com
>
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> Apache ServiceMix <http://servicemix.apache.org/> Committer
> *
>
--
View this message in context: http://servicemix.396122.n5.nabble.com/DISCUSS-Rebooting-ServiceMix-5-tp4528896p4542325.html
Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Re: [DISCUSS] Rebooting ServiceMix 5
Posted by Ioannis Canellos <io...@gmail.com>.
I am really happy to see the rebooting of Service Mix 5.
I agree with most of the points mentioned but I am skeptic about the tomcat
deployment.
I will skip talking about the advantages of such deployment option, since I
consider them obvious to all. I am worried on what it will mean to the pure
OSGi deployments (e.g. restrict the usage of OSGi APIs? Use of a framework
like pojosr?).
Any thoughts?
--
*Ioannis Canellos*
*
http://iocanel.blogspot.com
Apache Karaf <http://karaf.apache.org/> Committer & PMC
Apache ServiceMix <http://servicemix.apache.org/> Committer
*
Re: [DISCUSS] Rebooting ServiceMix 5
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
I like the splatch website design also.
As we discussed for Karaf, moving the SMX website to use scalate
requires that we have a "nightly" deployment of the website to quickly
update the news section, etc.
Regards
JB
On 06/29/2011 09:33 AM, Guillaume Nodet wrote:
> If we do the same as Karaf, the scalate based web site mostly consist
> in non technical docs (downloads, community, irc, forums, etc...) and
> all the technical docs are in versioned manuals.
>
> ServiceMix has a particularity though because we have several major
> versions which are really different, so that may affect a bit.
>
> Anyway, I really like the one splatch, so if he can give us the core
> images used in that web page, I'm sure we can make it work with the
> site Gert has worked on.
>
> On Wed, Jun 29, 2011 at 08:15, Lars Heinemann<lh...@apache.org> wrote:
>> Yes, I agree that we first should go for the content. But it's a bit wired as if we don't have so many sub pages as
>> in the current page then we will probably do content for pages which will not be used or in a different form.
>>
>> We should just have some basic idea how the sitemap will look like before flooding in the content.
>>
>> Best regards,
>> Lars
>>
>> --------------------------------------
>>
>> Lars Heinemann
>> FuseSource
>> Email: lhein@fusesource.com
>> Web: http://www.fusesource.com
>> Blog: http://lhein.blogspot.com
>> Twitter: lhein77
>>
>>
>>
>> Am 29.06.2011 um 08:03 schrieb Guillaume Nodet:
>>
>>> I don't have any problems with changing the design, but I just think
>>> that the content is more important than the color
>>>
>>> On Wed, Jun 29, 2011 at 07:39, Lars Heinemann<lh...@apache.org> wrote:
>>>> Regarding the webpage design...
>>>>
>>>> As already stated I don't like the design of the webpage. It seems to be a duplicate of the Karaf homepage
>>>> and I can't see that the page is now more easy and clean as we once intended to do.
>>>
>>> Well, if I can slightly object, it's kinda the opposite, as Karaf has
>>> simply reused the ServiceMix design ;-)
>>>
>>>> I'd like to point you to the following design proposals which I think are really awesome looking...
>>>>
>>>> http://www.flickr.com/photos/ccustine/5390898666/sizes/l/ (from ccustine)
>>>> http://img259.imageshack.us/img259/1718/servicemix46.jpg (from splatch)
>>>>
>>>> Shouldn't we go for something like this? Those designs are awesome looking and have a very clear and simple navigation concept.
>>>
>>> Both looks really good to me, but before switching the css, we need to
>>> get the scalate stuff to work and the content up to date, so that we
>>> can switch to that new stuff asap.
>>> Then, we can propose changes on the pure css stuff (colors, images,
>>> icons etc...) based on the new website. Once we have the
>>> infrastructure in place, we can easily branch or experiment with css
>>> patches.
>>>
>>>> Wdyt?
>>>>
>>>> Best regards,
>>>> Lars
>>>>
>>>> --------------------------------------
>>>>
>>>> Lars Heinemann
>>>> FuseSource
>>>> Email: lhein@fusesource.com
>>>> Web: http://www.fusesource.com
>>>> Blog: http://lhein.blogspot.com
>>>> Twitter: lhein77
>>>>
>>>>
>>>>
>>>> Am 29.06.2011 um 01:39 schrieb Gert Vanthienen:
>>>>
>>>>> Guillaume,
>>>>>
>>>>>
>>>>> All this seems to make a lot of sense to me - let's drop the bits that
>>>>> don't bring any value (any more) and try to add value to the project
>>>>> by focusing on providing these container-level services to integration
>>>>> projects. I also like the idea for creating both a Tomcat and a Karaf
>>>>> based distribution. That way, people can start with the more familiar
>>>>> WAR deployment in a simple Tomcat container and, as they need the more
>>>>> advanced features, gently migrate to the full OSGi-goodness of the
>>>>> Karaf based distribution.
>>>>>
>>>>> For the website, I took an initial stab at migrating the relevant bits
>>>>> of existing website contents to a Scalate/Maven-based project at
>>>>> https://svn.apache.org/repos/asf/servicemix/website and pushed an
>>>>> initial copy of the result out to
>>>>> http://servicemix.apache.org/staging/ so we can start adding content
>>>>> again there until we're happy enough with the result to promote this
>>>>> to become the home page.
>>>>>
>>>>> Information about the current location/build/... of the documentation
>>>>> project can be found at
>>>>> http://servicemix.apache.org/documentation-project.html - we have a
>>>>> bit of content for ServiceMix 4.x in there already but it still needs
>>>>> quite some work. For ServiceMix 5.x, we should probably grow the
>>>>> habit of documenting every single feature the moment we add it to the
>>>>> codebase right from the start so we can build the documentation right
>>>>> along with the actual code.
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> Gert Vanthienen
>>>>> ------------------------
>>>>> FuseSource
>>>>> Web: http://fusesource.com
>>>>> Blog: http://gertvanthienen.blogspot.com/
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Jun 27, 2011 at 5:54 PM, Guillaume Nodet<gn...@gmail.com> wrote:
>>>>>> Last week, I've been discussing with a few committers about the
>>>>>> ServiceMix roadmap.
>>>>>> So I'd like to communicate those thoughts to a wider audience.
>>>>>>
>>>>>> We've been discussing already that the value of ServiceMix (which was
>>>>>> the JBI layer in ServiceMix 3
>>>>>> and the container side in ServiceMix 4) has moved mostly to Camel and
>>>>>> Karaf respectively. The remainining
>>>>>> bits are mostly the NMR. However, the value of the NMR is not in the
>>>>>> NMR itself, but rather the NMR was
>>>>>> supposed to enable various container-level features. However, we
>>>>>> haven't really built those features so
>>>>>> that the *real* value of the NMR is not that high currently.
>>>>>>
>>>>>> So, what we've been discussing is to focus on that added value in a
>>>>>> more transparent way by tweaking
>>>>>> Camel a bit to support global interceptors, so that one could deploy
>>>>>> the real routes without having to
>>>>>> force the use of a specific transport such as the current NMR. This
>>>>>> way, a user could test / develop
>>>>>> the Camel routes or take existing Camel routes and deploy them in
>>>>>> ServiceMix, thereby transparently
>>>>>> enabling a bunch of useful features. We've been thinking about adding
>>>>>> message tracing / timing / auditing,
>>>>>> sending test messages, security checks, viewing flows, persistent
>>>>>> modification of camel
>>>>>> routes, camel route versioning, etc... That need to be coupled with a
>>>>>> web console similar to the
>>>>>> Camel / ActiveMQ web consoles, to actually display all the data to
>>>>>> provide useful information for monitoring
>>>>>> Camel routes and help diagnosing problems in production for example.
>>>>>> There's really nothing magically new
>>>>>> here and some of those features were actually part of ServiceMix 3,
>>>>>> but without much focus on those and
>>>>>> they have always kept a bit on the side. The idea is really to make
>>>>>> ServiceMix the best possible container
>>>>>> for deploying Camel based integration.
>>>>>>
>>>>>> Additional things that could be pushed inside ServiceMix 5 would be a
>>>>>> Tomcat based container deployment
>>>>>> option (for those that don't need OSGi), a new manual similar to what
>>>>>> we have in Karaf (maybe reusing
>>>>>> parts of it). We'd also need a new website (without the technical
>>>>>> doc, as we have for Karaf I think).
>>>>>>
>>>>>> On the maintenance of the JBI components and NMR/JBI layer, I think we
>>>>>> should keep them in smx4.
>>>>>> People wanting to deploy those could easily add a pointer to the
>>>>>> servicemix 4 features descriptors and
>>>>>> deploy the needed features. So we could officially deprecate those
>>>>>> and tell users they won't be
>>>>>> available in smx5. This also means that there's really not much to
>>>>>> reuse from smx4, so smx5 would
>>>>>> have its own new and dedicated svn area.
>>>>>>
>>>>>> FWIW, I plan to devote a big chunk of my time on ServiceMix 5 in the
>>>>>> coming months, so those are not
>>>>>> faithful wishes, but really something I want to start implementing asap.
>>>>>>
>>>>>> Feedback welcomed!
>>>>>>
>>>>>> --
>>>>>> ------------------------
>>>>>> Guillaume Nodet
>>>>>> ------------------------
>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>> ------------------------
>>>>>> Open Source SOA
>>>>>> http://fusesource.com
>>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> ------------------------
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>
>>
>
>
>
Re: [DISCUSS] Rebooting ServiceMix 5
Posted by Guillaume Nodet <gn...@gmail.com>.
If we do the same as Karaf, the scalate based web site mostly consist
in non technical docs (downloads, community, irc, forums, etc...) and
all the technical docs are in versioned manuals.
ServiceMix has a particularity though because we have several major
versions which are really different, so that may affect a bit.
Anyway, I really like the one splatch, so if he can give us the core
images used in that web page, I'm sure we can make it work with the
site Gert has worked on.
On Wed, Jun 29, 2011 at 08:15, Lars Heinemann <lh...@apache.org> wrote:
> Yes, I agree that we first should go for the content. But it's a bit wired as if we don't have so many sub pages as
> in the current page then we will probably do content for pages which will not be used or in a different form.
>
> We should just have some basic idea how the sitemap will look like before flooding in the content.
>
> Best regards,
> Lars
>
> --------------------------------------
>
> Lars Heinemann
> FuseSource
> Email: lhein@fusesource.com
> Web: http://www.fusesource.com
> Blog: http://lhein.blogspot.com
> Twitter: lhein77
>
>
>
> Am 29.06.2011 um 08:03 schrieb Guillaume Nodet:
>
>> I don't have any problems with changing the design, but I just think
>> that the content is more important than the color
>>
>> On Wed, Jun 29, 2011 at 07:39, Lars Heinemann <lh...@apache.org> wrote:
>>> Regarding the webpage design...
>>>
>>> As already stated I don't like the design of the webpage. It seems to be a duplicate of the Karaf homepage
>>> and I can't see that the page is now more easy and clean as we once intended to do.
>>
>> Well, if I can slightly object, it's kinda the opposite, as Karaf has
>> simply reused the ServiceMix design ;-)
>>
>>> I'd like to point you to the following design proposals which I think are really awesome looking...
>>>
>>> http://www.flickr.com/photos/ccustine/5390898666/sizes/l/ (from ccustine)
>>> http://img259.imageshack.us/img259/1718/servicemix46.jpg (from splatch)
>>>
>>> Shouldn't we go for something like this? Those designs are awesome looking and have a very clear and simple navigation concept.
>>
>> Both looks really good to me, but before switching the css, we need to
>> get the scalate stuff to work and the content up to date, so that we
>> can switch to that new stuff asap.
>> Then, we can propose changes on the pure css stuff (colors, images,
>> icons etc...) based on the new website. Once we have the
>> infrastructure in place, we can easily branch or experiment with css
>> patches.
>>
>>> Wdyt?
>>>
>>> Best regards,
>>> Lars
>>>
>>> --------------------------------------
>>>
>>> Lars Heinemann
>>> FuseSource
>>> Email: lhein@fusesource.com
>>> Web: http://www.fusesource.com
>>> Blog: http://lhein.blogspot.com
>>> Twitter: lhein77
>>>
>>>
>>>
>>> Am 29.06.2011 um 01:39 schrieb Gert Vanthienen:
>>>
>>>> Guillaume,
>>>>
>>>>
>>>> All this seems to make a lot of sense to me - let's drop the bits that
>>>> don't bring any value (any more) and try to add value to the project
>>>> by focusing on providing these container-level services to integration
>>>> projects. I also like the idea for creating both a Tomcat and a Karaf
>>>> based distribution. That way, people can start with the more familiar
>>>> WAR deployment in a simple Tomcat container and, as they need the more
>>>> advanced features, gently migrate to the full OSGi-goodness of the
>>>> Karaf based distribution.
>>>>
>>>> For the website, I took an initial stab at migrating the relevant bits
>>>> of existing website contents to a Scalate/Maven-based project at
>>>> https://svn.apache.org/repos/asf/servicemix/website and pushed an
>>>> initial copy of the result out to
>>>> http://servicemix.apache.org/staging/ so we can start adding content
>>>> again there until we're happy enough with the result to promote this
>>>> to become the home page.
>>>>
>>>> Information about the current location/build/... of the documentation
>>>> project can be found at
>>>> http://servicemix.apache.org/documentation-project.html - we have a
>>>> bit of content for ServiceMix 4.x in there already but it still needs
>>>> quite some work. For ServiceMix 5.x, we should probably grow the
>>>> habit of documenting every single feature the moment we add it to the
>>>> codebase right from the start so we can build the documentation right
>>>> along with the actual code.
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Gert Vanthienen
>>>> ------------------------
>>>> FuseSource
>>>> Web: http://fusesource.com
>>>> Blog: http://gertvanthienen.blogspot.com/
>>>>
>>>>
>>>>
>>>> On Mon, Jun 27, 2011 at 5:54 PM, Guillaume Nodet <gn...@gmail.com> wrote:
>>>>> Last week, I've been discussing with a few committers about the
>>>>> ServiceMix roadmap.
>>>>> So I'd like to communicate those thoughts to a wider audience.
>>>>>
>>>>> We've been discussing already that the value of ServiceMix (which was
>>>>> the JBI layer in ServiceMix 3
>>>>> and the container side in ServiceMix 4) has moved mostly to Camel and
>>>>> Karaf respectively. The remainining
>>>>> bits are mostly the NMR. However, the value of the NMR is not in the
>>>>> NMR itself, but rather the NMR was
>>>>> supposed to enable various container-level features. However, we
>>>>> haven't really built those features so
>>>>> that the *real* value of the NMR is not that high currently.
>>>>>
>>>>> So, what we've been discussing is to focus on that added value in a
>>>>> more transparent way by tweaking
>>>>> Camel a bit to support global interceptors, so that one could deploy
>>>>> the real routes without having to
>>>>> force the use of a specific transport such as the current NMR. This
>>>>> way, a user could test / develop
>>>>> the Camel routes or take existing Camel routes and deploy them in
>>>>> ServiceMix, thereby transparently
>>>>> enabling a bunch of useful features. We've been thinking about adding
>>>>> message tracing / timing / auditing,
>>>>> sending test messages, security checks, viewing flows, persistent
>>>>> modification of camel
>>>>> routes, camel route versioning, etc... That need to be coupled with a
>>>>> web console similar to the
>>>>> Camel / ActiveMQ web consoles, to actually display all the data to
>>>>> provide useful information for monitoring
>>>>> Camel routes and help diagnosing problems in production for example.
>>>>> There's really nothing magically new
>>>>> here and some of those features were actually part of ServiceMix 3,
>>>>> but without much focus on those and
>>>>> they have always kept a bit on the side. The idea is really to make
>>>>> ServiceMix the best possible container
>>>>> for deploying Camel based integration.
>>>>>
>>>>> Additional things that could be pushed inside ServiceMix 5 would be a
>>>>> Tomcat based container deployment
>>>>> option (for those that don't need OSGi), a new manual similar to what
>>>>> we have in Karaf (maybe reusing
>>>>> parts of it). We'd also need a new website (without the technical
>>>>> doc, as we have for Karaf I think).
>>>>>
>>>>> On the maintenance of the JBI components and NMR/JBI layer, I think we
>>>>> should keep them in smx4.
>>>>> People wanting to deploy those could easily add a pointer to the
>>>>> servicemix 4 features descriptors and
>>>>> deploy the needed features. So we could officially deprecate those
>>>>> and tell users they won't be
>>>>> available in smx5. This also means that there's really not much to
>>>>> reuse from smx4, so smx5 would
>>>>> have its own new and dedicated svn area.
>>>>>
>>>>> FWIW, I plan to devote a big chunk of my time on ServiceMix 5 in the
>>>>> coming months, so those are not
>>>>> faithful wishes, but really something I want to start implementing asap.
>>>>>
>>>>> Feedback welcomed!
>>>>>
>>>>> --
>>>>> ------------------------
>>>>> Guillaume Nodet
>>>>> ------------------------
>>>>> Blog: http://gnodet.blogspot.com/
>>>>> ------------------------
>>>>> Open Source SOA
>>>>> http://fusesource.com
>>>>>
>>>
>>>
>>
>>
>>
>> --
>> ------------------------
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>
>
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSS] Rebooting ServiceMix 5
Posted by Lars Heinemann <lh...@apache.org>.
Yes, I agree that we first should go for the content. But it's a bit wired as if we don't have so many sub pages as
in the current page then we will probably do content for pages which will not be used or in a different form.
We should just have some basic idea how the sitemap will look like before flooding in the content.
Best regards,
Lars
--------------------------------------
Lars Heinemann
FuseSource
Email: lhein@fusesource.com
Web: http://www.fusesource.com
Blog: http://lhein.blogspot.com
Twitter: lhein77
Am 29.06.2011 um 08:03 schrieb Guillaume Nodet:
> I don't have any problems with changing the design, but I just think
> that the content is more important than the color
>
> On Wed, Jun 29, 2011 at 07:39, Lars Heinemann <lh...@apache.org> wrote:
>> Regarding the webpage design...
>>
>> As already stated I don't like the design of the webpage. It seems to be a duplicate of the Karaf homepage
>> and I can't see that the page is now more easy and clean as we once intended to do.
>
> Well, if I can slightly object, it's kinda the opposite, as Karaf has
> simply reused the ServiceMix design ;-)
>
>> I'd like to point you to the following design proposals which I think are really awesome looking...
>>
>> http://www.flickr.com/photos/ccustine/5390898666/sizes/l/ (from ccustine)
>> http://img259.imageshack.us/img259/1718/servicemix46.jpg (from splatch)
>>
>> Shouldn't we go for something like this? Those designs are awesome looking and have a very clear and simple navigation concept.
>
> Both looks really good to me, but before switching the css, we need to
> get the scalate stuff to work and the content up to date, so that we
> can switch to that new stuff asap.
> Then, we can propose changes on the pure css stuff (colors, images,
> icons etc...) based on the new website. Once we have the
> infrastructure in place, we can easily branch or experiment with css
> patches.
>
>> Wdyt?
>>
>> Best regards,
>> Lars
>>
>> --------------------------------------
>>
>> Lars Heinemann
>> FuseSource
>> Email: lhein@fusesource.com
>> Web: http://www.fusesource.com
>> Blog: http://lhein.blogspot.com
>> Twitter: lhein77
>>
>>
>>
>> Am 29.06.2011 um 01:39 schrieb Gert Vanthienen:
>>
>>> Guillaume,
>>>
>>>
>>> All this seems to make a lot of sense to me - let's drop the bits that
>>> don't bring any value (any more) and try to add value to the project
>>> by focusing on providing these container-level services to integration
>>> projects. I also like the idea for creating both a Tomcat and a Karaf
>>> based distribution. That way, people can start with the more familiar
>>> WAR deployment in a simple Tomcat container and, as they need the more
>>> advanced features, gently migrate to the full OSGi-goodness of the
>>> Karaf based distribution.
>>>
>>> For the website, I took an initial stab at migrating the relevant bits
>>> of existing website contents to a Scalate/Maven-based project at
>>> https://svn.apache.org/repos/asf/servicemix/website and pushed an
>>> initial copy of the result out to
>>> http://servicemix.apache.org/staging/ so we can start adding content
>>> again there until we're happy enough with the result to promote this
>>> to become the home page.
>>>
>>> Information about the current location/build/... of the documentation
>>> project can be found at
>>> http://servicemix.apache.org/documentation-project.html - we have a
>>> bit of content for ServiceMix 4.x in there already but it still needs
>>> quite some work. For ServiceMix 5.x, we should probably grow the
>>> habit of documenting every single feature the moment we add it to the
>>> codebase right from the start so we can build the documentation right
>>> along with the actual code.
>>>
>>>
>>> Regards,
>>>
>>> Gert Vanthienen
>>> ------------------------
>>> FuseSource
>>> Web: http://fusesource.com
>>> Blog: http://gertvanthienen.blogspot.com/
>>>
>>>
>>>
>>> On Mon, Jun 27, 2011 at 5:54 PM, Guillaume Nodet <gn...@gmail.com> wrote:
>>>> Last week, I've been discussing with a few committers about the
>>>> ServiceMix roadmap.
>>>> So I'd like to communicate those thoughts to a wider audience.
>>>>
>>>> We've been discussing already that the value of ServiceMix (which was
>>>> the JBI layer in ServiceMix 3
>>>> and the container side in ServiceMix 4) has moved mostly to Camel and
>>>> Karaf respectively. The remainining
>>>> bits are mostly the NMR. However, the value of the NMR is not in the
>>>> NMR itself, but rather the NMR was
>>>> supposed to enable various container-level features. However, we
>>>> haven't really built those features so
>>>> that the *real* value of the NMR is not that high currently.
>>>>
>>>> So, what we've been discussing is to focus on that added value in a
>>>> more transparent way by tweaking
>>>> Camel a bit to support global interceptors, so that one could deploy
>>>> the real routes without having to
>>>> force the use of a specific transport such as the current NMR. This
>>>> way, a user could test / develop
>>>> the Camel routes or take existing Camel routes and deploy them in
>>>> ServiceMix, thereby transparently
>>>> enabling a bunch of useful features. We've been thinking about adding
>>>> message tracing / timing / auditing,
>>>> sending test messages, security checks, viewing flows, persistent
>>>> modification of camel
>>>> routes, camel route versioning, etc... That need to be coupled with a
>>>> web console similar to the
>>>> Camel / ActiveMQ web consoles, to actually display all the data to
>>>> provide useful information for monitoring
>>>> Camel routes and help diagnosing problems in production for example.
>>>> There's really nothing magically new
>>>> here and some of those features were actually part of ServiceMix 3,
>>>> but without much focus on those and
>>>> they have always kept a bit on the side. The idea is really to make
>>>> ServiceMix the best possible container
>>>> for deploying Camel based integration.
>>>>
>>>> Additional things that could be pushed inside ServiceMix 5 would be a
>>>> Tomcat based container deployment
>>>> option (for those that don't need OSGi), a new manual similar to what
>>>> we have in Karaf (maybe reusing
>>>> parts of it). We'd also need a new website (without the technical
>>>> doc, as we have for Karaf I think).
>>>>
>>>> On the maintenance of the JBI components and NMR/JBI layer, I think we
>>>> should keep them in smx4.
>>>> People wanting to deploy those could easily add a pointer to the
>>>> servicemix 4 features descriptors and
>>>> deploy the needed features. So we could officially deprecate those
>>>> and tell users they won't be
>>>> available in smx5. This also means that there's really not much to
>>>> reuse from smx4, so smx5 would
>>>> have its own new and dedicated svn area.
>>>>
>>>> FWIW, I plan to devote a big chunk of my time on ServiceMix 5 in the
>>>> coming months, so those are not
>>>> faithful wishes, but really something I want to start implementing asap.
>>>>
>>>> Feedback welcomed!
>>>>
>>>> --
>>>> ------------------------
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Blog: http://gnodet.blogspot.com/
>>>> ------------------------
>>>> Open Source SOA
>>>> http://fusesource.com
>>>>
>>
>>
>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
Re: [DISCUSS] Rebooting ServiceMix 5
Posted by Guillaume Nodet <gn...@gmail.com>.
I don't have any problems with changing the design, but I just think
that the content is more important than the color
On Wed, Jun 29, 2011 at 07:39, Lars Heinemann <lh...@apache.org> wrote:
> Regarding the webpage design...
>
> As already stated I don't like the design of the webpage. It seems to be a duplicate of the Karaf homepage
> and I can't see that the page is now more easy and clean as we once intended to do.
Well, if I can slightly object, it's kinda the opposite, as Karaf has
simply reused the ServiceMix design ;-)
> I'd like to point you to the following design proposals which I think are really awesome looking...
>
> http://www.flickr.com/photos/ccustine/5390898666/sizes/l/ (from ccustine)
> http://img259.imageshack.us/img259/1718/servicemix46.jpg (from splatch)
>
> Shouldn't we go for something like this? Those designs are awesome looking and have a very clear and simple navigation concept.
Both looks really good to me, but before switching the css, we need to
get the scalate stuff to work and the content up to date, so that we
can switch to that new stuff asap.
Then, we can propose changes on the pure css stuff (colors, images,
icons etc...) based on the new website. Once we have the
infrastructure in place, we can easily branch or experiment with css
patches.
> Wdyt?
>
> Best regards,
> Lars
>
> --------------------------------------
>
> Lars Heinemann
> FuseSource
> Email: lhein@fusesource.com
> Web: http://www.fusesource.com
> Blog: http://lhein.blogspot.com
> Twitter: lhein77
>
>
>
> Am 29.06.2011 um 01:39 schrieb Gert Vanthienen:
>
>> Guillaume,
>>
>>
>> All this seems to make a lot of sense to me - let's drop the bits that
>> don't bring any value (any more) and try to add value to the project
>> by focusing on providing these container-level services to integration
>> projects. I also like the idea for creating both a Tomcat and a Karaf
>> based distribution. That way, people can start with the more familiar
>> WAR deployment in a simple Tomcat container and, as they need the more
>> advanced features, gently migrate to the full OSGi-goodness of the
>> Karaf based distribution.
>>
>> For the website, I took an initial stab at migrating the relevant bits
>> of existing website contents to a Scalate/Maven-based project at
>> https://svn.apache.org/repos/asf/servicemix/website and pushed an
>> initial copy of the result out to
>> http://servicemix.apache.org/staging/ so we can start adding content
>> again there until we're happy enough with the result to promote this
>> to become the home page.
>>
>> Information about the current location/build/... of the documentation
>> project can be found at
>> http://servicemix.apache.org/documentation-project.html - we have a
>> bit of content for ServiceMix 4.x in there already but it still needs
>> quite some work. For ServiceMix 5.x, we should probably grow the
>> habit of documenting every single feature the moment we add it to the
>> codebase right from the start so we can build the documentation right
>> along with the actual code.
>>
>>
>> Regards,
>>
>> Gert Vanthienen
>> ------------------------
>> FuseSource
>> Web: http://fusesource.com
>> Blog: http://gertvanthienen.blogspot.com/
>>
>>
>>
>> On Mon, Jun 27, 2011 at 5:54 PM, Guillaume Nodet <gn...@gmail.com> wrote:
>>> Last week, I've been discussing with a few committers about the
>>> ServiceMix roadmap.
>>> So I'd like to communicate those thoughts to a wider audience.
>>>
>>> We've been discussing already that the value of ServiceMix (which was
>>> the JBI layer in ServiceMix 3
>>> and the container side in ServiceMix 4) has moved mostly to Camel and
>>> Karaf respectively. The remainining
>>> bits are mostly the NMR. However, the value of the NMR is not in the
>>> NMR itself, but rather the NMR was
>>> supposed to enable various container-level features. However, we
>>> haven't really built those features so
>>> that the *real* value of the NMR is not that high currently.
>>>
>>> So, what we've been discussing is to focus on that added value in a
>>> more transparent way by tweaking
>>> Camel a bit to support global interceptors, so that one could deploy
>>> the real routes without having to
>>> force the use of a specific transport such as the current NMR. This
>>> way, a user could test / develop
>>> the Camel routes or take existing Camel routes and deploy them in
>>> ServiceMix, thereby transparently
>>> enabling a bunch of useful features. We've been thinking about adding
>>> message tracing / timing / auditing,
>>> sending test messages, security checks, viewing flows, persistent
>>> modification of camel
>>> routes, camel route versioning, etc... That need to be coupled with a
>>> web console similar to the
>>> Camel / ActiveMQ web consoles, to actually display all the data to
>>> provide useful information for monitoring
>>> Camel routes and help diagnosing problems in production for example.
>>> There's really nothing magically new
>>> here and some of those features were actually part of ServiceMix 3,
>>> but without much focus on those and
>>> they have always kept a bit on the side. The idea is really to make
>>> ServiceMix the best possible container
>>> for deploying Camel based integration.
>>>
>>> Additional things that could be pushed inside ServiceMix 5 would be a
>>> Tomcat based container deployment
>>> option (for those that don't need OSGi), a new manual similar to what
>>> we have in Karaf (maybe reusing
>>> parts of it). We'd also need a new website (without the technical
>>> doc, as we have for Karaf I think).
>>>
>>> On the maintenance of the JBI components and NMR/JBI layer, I think we
>>> should keep them in smx4.
>>> People wanting to deploy those could easily add a pointer to the
>>> servicemix 4 features descriptors and
>>> deploy the needed features. So we could officially deprecate those
>>> and tell users they won't be
>>> available in smx5. This also means that there's really not much to
>>> reuse from smx4, so smx5 would
>>> have its own new and dedicated svn area.
>>>
>>> FWIW, I plan to devote a big chunk of my time on ServiceMix 5 in the
>>> coming months, so those are not
>>> faithful wishes, but really something I want to start implementing asap.
>>>
>>> Feedback welcomed!
>>>
>>> --
>>> ------------------------
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>>
>
>
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSS] Rebooting ServiceMix 5
Posted by Lars Heinemann <lh...@apache.org>.
Regarding the webpage design...
As already stated I don't like the design of the webpage. It seems to be a duplicate of the Karaf homepage
and I can't see that the page is now more easy and clean as we once intended to do.
I'd like to point you to the following design proposals which I think are really awesome looking...
http://www.flickr.com/photos/ccustine/5390898666/sizes/l/ (from ccustine)
http://img259.imageshack.us/img259/1718/servicemix46.jpg (from splatch)
Shouldn't we go for something like this? Those designs are awesome looking and have a very clear and simple navigation concept.
Wdyt?
Best regards,
Lars
--------------------------------------
Lars Heinemann
FuseSource
Email: lhein@fusesource.com
Web: http://www.fusesource.com
Blog: http://lhein.blogspot.com
Twitter: lhein77
Am 29.06.2011 um 01:39 schrieb Gert Vanthienen:
> Guillaume,
>
>
> All this seems to make a lot of sense to me - let's drop the bits that
> don't bring any value (any more) and try to add value to the project
> by focusing on providing these container-level services to integration
> projects. I also like the idea for creating both a Tomcat and a Karaf
> based distribution. That way, people can start with the more familiar
> WAR deployment in a simple Tomcat container and, as they need the more
> advanced features, gently migrate to the full OSGi-goodness of the
> Karaf based distribution.
>
> For the website, I took an initial stab at migrating the relevant bits
> of existing website contents to a Scalate/Maven-based project at
> https://svn.apache.org/repos/asf/servicemix/website and pushed an
> initial copy of the result out to
> http://servicemix.apache.org/staging/ so we can start adding content
> again there until we're happy enough with the result to promote this
> to become the home page.
>
> Information about the current location/build/... of the documentation
> project can be found at
> http://servicemix.apache.org/documentation-project.html - we have a
> bit of content for ServiceMix 4.x in there already but it still needs
> quite some work. For ServiceMix 5.x, we should probably grow the
> habit of documenting every single feature the moment we add it to the
> codebase right from the start so we can build the documentation right
> along with the actual code.
>
>
> Regards,
>
> Gert Vanthienen
> ------------------------
> FuseSource
> Web: http://fusesource.com
> Blog: http://gertvanthienen.blogspot.com/
>
>
>
> On Mon, Jun 27, 2011 at 5:54 PM, Guillaume Nodet <gn...@gmail.com> wrote:
>> Last week, I've been discussing with a few committers about the
>> ServiceMix roadmap.
>> So I'd like to communicate those thoughts to a wider audience.
>>
>> We've been discussing already that the value of ServiceMix (which was
>> the JBI layer in ServiceMix 3
>> and the container side in ServiceMix 4) has moved mostly to Camel and
>> Karaf respectively. The remainining
>> bits are mostly the NMR. However, the value of the NMR is not in the
>> NMR itself, but rather the NMR was
>> supposed to enable various container-level features. However, we
>> haven't really built those features so
>> that the *real* value of the NMR is not that high currently.
>>
>> So, what we've been discussing is to focus on that added value in a
>> more transparent way by tweaking
>> Camel a bit to support global interceptors, so that one could deploy
>> the real routes without having to
>> force the use of a specific transport such as the current NMR. This
>> way, a user could test / develop
>> the Camel routes or take existing Camel routes and deploy them in
>> ServiceMix, thereby transparently
>> enabling a bunch of useful features. We've been thinking about adding
>> message tracing / timing / auditing,
>> sending test messages, security checks, viewing flows, persistent
>> modification of camel
>> routes, camel route versioning, etc... That need to be coupled with a
>> web console similar to the
>> Camel / ActiveMQ web consoles, to actually display all the data to
>> provide useful information for monitoring
>> Camel routes and help diagnosing problems in production for example.
>> There's really nothing magically new
>> here and some of those features were actually part of ServiceMix 3,
>> but without much focus on those and
>> they have always kept a bit on the side. The idea is really to make
>> ServiceMix the best possible container
>> for deploying Camel based integration.
>>
>> Additional things that could be pushed inside ServiceMix 5 would be a
>> Tomcat based container deployment
>> option (for those that don't need OSGi), a new manual similar to what
>> we have in Karaf (maybe reusing
>> parts of it). We'd also need a new website (without the technical
>> doc, as we have for Karaf I think).
>>
>> On the maintenance of the JBI components and NMR/JBI layer, I think we
>> should keep them in smx4.
>> People wanting to deploy those could easily add a pointer to the
>> servicemix 4 features descriptors and
>> deploy the needed features. So we could officially deprecate those
>> and tell users they won't be
>> available in smx5. This also means that there's really not much to
>> reuse from smx4, so smx5 would
>> have its own new and dedicated svn area.
>>
>> FWIW, I plan to devote a big chunk of my time on ServiceMix 5 in the
>> coming months, so those are not
>> faithful wishes, but really something I want to start implementing asap.
>>
>> Feedback welcomed!
>>
>> --
>> ------------------------
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
Re: [DISCUSS] Rebooting ServiceMix 5
Posted by Gert Vanthienen <ge...@gmail.com>.
Guillaume,
All this seems to make a lot of sense to me - let's drop the bits that
don't bring any value (any more) and try to add value to the project
by focusing on providing these container-level services to integration
projects. I also like the idea for creating both a Tomcat and a Karaf
based distribution. That way, people can start with the more familiar
WAR deployment in a simple Tomcat container and, as they need the more
advanced features, gently migrate to the full OSGi-goodness of the
Karaf based distribution.
For the website, I took an initial stab at migrating the relevant bits
of existing website contents to a Scalate/Maven-based project at
https://svn.apache.org/repos/asf/servicemix/website and pushed an
initial copy of the result out to
http://servicemix.apache.org/staging/ so we can start adding content
again there until we're happy enough with the result to promote this
to become the home page.
Information about the current location/build/... of the documentation
project can be found at
http://servicemix.apache.org/documentation-project.html - we have a
bit of content for ServiceMix 4.x in there already but it still needs
quite some work. For ServiceMix 5.x, we should probably grow the
habit of documenting every single feature the moment we add it to the
codebase right from the start so we can build the documentation right
along with the actual code.
Regards,
Gert Vanthienen
------------------------
FuseSource
Web: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/
On Mon, Jun 27, 2011 at 5:54 PM, Guillaume Nodet <gn...@gmail.com> wrote:
> Last week, I've been discussing with a few committers about the
> ServiceMix roadmap.
> So I'd like to communicate those thoughts to a wider audience.
>
> We've been discussing already that the value of ServiceMix (which was
> the JBI layer in ServiceMix 3
> and the container side in ServiceMix 4) has moved mostly to Camel and
> Karaf respectively. The remainining
> bits are mostly the NMR. However, the value of the NMR is not in the
> NMR itself, but rather the NMR was
> supposed to enable various container-level features. However, we
> haven't really built those features so
> that the *real* value of the NMR is not that high currently.
>
> So, what we've been discussing is to focus on that added value in a
> more transparent way by tweaking
> Camel a bit to support global interceptors, so that one could deploy
> the real routes without having to
> force the use of a specific transport such as the current NMR. This
> way, a user could test / develop
> the Camel routes or take existing Camel routes and deploy them in
> ServiceMix, thereby transparently
> enabling a bunch of useful features. We've been thinking about adding
> message tracing / timing / auditing,
> sending test messages, security checks, viewing flows, persistent
> modification of camel
> routes, camel route versioning, etc... That need to be coupled with a
> web console similar to the
> Camel / ActiveMQ web consoles, to actually display all the data to
> provide useful information for monitoring
> Camel routes and help diagnosing problems in production for example.
> There's really nothing magically new
> here and some of those features were actually part of ServiceMix 3,
> but without much focus on those and
> they have always kept a bit on the side. The idea is really to make
> ServiceMix the best possible container
> for deploying Camel based integration.
>
> Additional things that could be pushed inside ServiceMix 5 would be a
> Tomcat based container deployment
> option (for those that don't need OSGi), a new manual similar to what
> we have in Karaf (maybe reusing
> parts of it). We'd also need a new website (without the technical
> doc, as we have for Karaf I think).
>
> On the maintenance of the JBI components and NMR/JBI layer, I think we
> should keep them in smx4.
> People wanting to deploy those could easily add a pointer to the
> servicemix 4 features descriptors and
> deploy the needed features. So we could officially deprecate those
> and tell users they won't be
> available in smx5. This also means that there's really not much to
> reuse from smx4, so smx5 would
> have its own new and dedicated svn area.
>
> FWIW, I plan to devote a big chunk of my time on ServiceMix 5 in the
> coming months, so those are not
> faithful wishes, but really something I want to start implementing asap.
>
> Feedback welcomed!
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
Re: [DISCUSS] Rebooting ServiceMix 5
Posted by Charles Moulliard <cm...@gmail.com>.
Hi Guillaume,
This is definitively the way to go for SMX5, integrate NMR as the
communication layer within SMX and providing features with added value
like you propose. BTW, it should also be great if we can externalize
the Tx behavior and define it when we will register the Camel Tx
endpoints in SMX5 (like jms, jdbc, jpa, ....). That will simplify the
development, .... The debate regarding Tomcat <-> SMX5 <--> OSGI will
continue in another threads/emails/... but I don t think that
packaging SMX5 + Tomcat will help clients/projects as they already
have Tomcat, JBoss, WebSphere but require to deploy SMX5 (with or
without OSGI) + Camel for Tx purpose, Auditing, Security, Tracing,
.... into their container. Do you know a lot of client using TomEE of
OpenEJB (http://openejb.apache.org/3.0/apache-tomee.html). No and that
will be the case if we promote a TomEE for SMX5.
Just my 2 cents opinion ;-)
Regards,
Charles
On Mon, Jun 27, 2011 at 5:54 PM, Guillaume Nodet <gn...@gmail.com> wrote:
> Last week, I've been discussing with a few committers about the
> ServiceMix roadmap.
> So I'd like to communicate those thoughts to a wider audience.
>
> We've been discussing already that the value of ServiceMix (which was
> the JBI layer in ServiceMix 3
> and the container side in ServiceMix 4) has moved mostly to Camel and
> Karaf respectively. The remainining
> bits are mostly the NMR. However, the value of the NMR is not in the
> NMR itself, but rather the NMR was
> supposed to enable various container-level features. However, we
> haven't really built those features so
> that the *real* value of the NMR is not that high currently.
>
> So, what we've been discussing is to focus on that added value in a
> more transparent way by tweaking
> Camel a bit to support global interceptors, so that one could deploy
> the real routes without having to
> force the use of a specific transport such as the current NMR. This
> way, a user could test / develop
> the Camel routes or take existing Camel routes and deploy them in
> ServiceMix, thereby transparently
> enabling a bunch of useful features. We've been thinking about adding
> message tracing / timing / auditing,
> sending test messages, security checks, viewing flows, persistent
> modification of camel
> routes, camel route versioning, etc... That need to be coupled with a
> web console similar to the
> Camel / ActiveMQ web consoles, to actually display all the data to
> provide useful information for monitoring
> Camel routes and help diagnosing problems in production for example.
> There's really nothing magically new
> here and some of those features were actually part of ServiceMix 3,
> but without much focus on those and
> they have always kept a bit on the side. The idea is really to make
> ServiceMix the best possible container
> for deploying Camel based integration.
>
> Additional things that could be pushed inside ServiceMix 5 would be a
> Tomcat based container deployment
> option (for those that don't need OSGi), a new manual similar to what
> we have in Karaf (maybe reusing
> parts of it). We'd also need a new website (without the technical
> doc, as we have for Karaf I think).
>
> On the maintenance of the JBI components and NMR/JBI layer, I think we
> should keep them in smx4.
> People wanting to deploy those could easily add a pointer to the
> servicemix 4 features descriptors and
> deploy the needed features. So we could officially deprecate those
> and tell users they won't be
> available in smx5. This also means that there's really not much to
> reuse from smx4, so smx5 would
> have its own new and dedicated svn area.
>
> FWIW, I plan to devote a big chunk of my time on ServiceMix 5 in the
> coming months, so those are not
> faithful wishes, but really something I want to start implementing asap.
>
> Feedback welcomed!
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
Re: [DISCUSS] Rebooting ServiceMix 5
Posted by Freeman Fang <fr...@gmail.com>.
Totally agree.
Deploy an OSGi container into Web/servlet container like tomcat IMHO
is weird. Users actually needn't deploy one container into another,
they just need figure out their real requirement and chose the proper
container. Moreover, the different classloader mechanism used by
different containers may bring more trouble if we mix them.
Best Regards
Freeman
On 2011-6-29, at 下午12:57, Gert Vanthienen wrote:
> Andreas, Willem,
>
> Packing up Karaf in Tomcat would be one way to do it, but I think we
> can also get away with a more plain Tomcat container for many of the
> use cases listed in Guillaume's mail - as long as we have Camel's core
> classes in a shared classloader (i.e. in the container's lib folder)
> and are able to inject a single dynamically modifiable interceptor
> into the Camel route, we can already do a lot of things like auditing,
> tracing, ...
>
> There are obviously quite a few things we can only do if we have a
> more dynamic runtime environment, but in my mind that's OK because
> that way we also have some good, compelling reasons to move people
> over to the Karaf runtime version and tell them about all the goodies
> of OSGi (we still all love OSGi and Karaf ourselves ;)). For advanced
> use cases, we should definitely guide users towards Karaf, but for a
> set of basic things, just using Tomcat and simple WARs may be the
> simplest thing that works for them!
>
> Regards,
>
> Gert Vanthienen
> ------------------------
> FuseSource
> Web: http://fusesource.com
> Blog: http://gertvanthienen.blogspot.com/
>
>
>
> On Wed, Jun 29, 2011 at 4:27 AM, Andreas Pieber <an...@gmail.com>
> wrote:
>> Hey Willem,
>>
>> You can pack Karaf right now into a WAR already and deploy it on an
>> Tomcat (see [1]).
>>
>> Kind regards,
>> Andreas
>>
>> [1] https://svn.apache.org/repos/asf/karaf/trunk/demos/web/
>>
>> On Wed, Jun 29, 2011 at 4:18 AM, Willem Jiang
>> <wi...@gmail.com> wrote:
>>> Hi Guillaume
>>>
>>> I just have a simple question for it.
>>> As you know Karaf is based on OSGi, I don't know how ServiceMix5
>>> can achieve
>>> this without leverage the OSGi? Do I missing something?
>>>
>>> On 6/27/11 11:54 PM, Guillaume Nodet wrote:
>>>>
>>>> Additional things that could be pushed inside ServiceMix 5 would
>>>> be a
>>>> Tomcat based container deployment
>>>> option (for those that don't need OSGi), a new manual similar to
>>>> what
>>>> we have in Karaf (maybe reusing
>>>> parts of it).
>>>
>>>
>>> --
>>> Willem
>>> ----------------------------------
>>> FuseSource
>>> Web: http://www.fusesource.com
>>> Blog: http://willemjiang.blogspot.com (English)
>>> http://jnn.javaeye.com (Chinese)
>>> Twitter: willemjiang
>>> Weibo: willemjiang
>>>
>>
---------------------------------------------
Freeman Fang
FuseSource
Email:ffang@fusesource.com
Web: fusesource.com
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
Re: [DISCUSS] Rebooting ServiceMix 5
Posted by Gert Vanthienen <ge...@gmail.com>.
Andreas, Willem,
Packing up Karaf in Tomcat would be one way to do it, but I think we
can also get away with a more plain Tomcat container for many of the
use cases listed in Guillaume's mail - as long as we have Camel's core
classes in a shared classloader (i.e. in the container's lib folder)
and are able to inject a single dynamically modifiable interceptor
into the Camel route, we can already do a lot of things like auditing,
tracing, ...
There are obviously quite a few things we can only do if we have a
more dynamic runtime environment, but in my mind that's OK because
that way we also have some good, compelling reasons to move people
over to the Karaf runtime version and tell them about all the goodies
of OSGi (we still all love OSGi and Karaf ourselves ;)). For advanced
use cases, we should definitely guide users towards Karaf, but for a
set of basic things, just using Tomcat and simple WARs may be the
simplest thing that works for them!
Regards,
Gert Vanthienen
------------------------
FuseSource
Web: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/
On Wed, Jun 29, 2011 at 4:27 AM, Andreas Pieber <an...@gmail.com> wrote:
> Hey Willem,
>
> You can pack Karaf right now into a WAR already and deploy it on an
> Tomcat (see [1]).
>
> Kind regards,
> Andreas
>
> [1] https://svn.apache.org/repos/asf/karaf/trunk/demos/web/
>
> On Wed, Jun 29, 2011 at 4:18 AM, Willem Jiang <wi...@gmail.com> wrote:
>> Hi Guillaume
>>
>> I just have a simple question for it.
>> As you know Karaf is based on OSGi, I don't know how ServiceMix5 can achieve
>> this without leverage the OSGi? Do I missing something?
>>
>> On 6/27/11 11:54 PM, Guillaume Nodet wrote:
>>>
>>> Additional things that could be pushed inside ServiceMix 5 would be a
>>> Tomcat based container deployment
>>> option (for those that don't need OSGi), a new manual similar to what
>>> we have in Karaf (maybe reusing
>>> parts of it).
>>
>>
>> --
>> Willem
>> ----------------------------------
>> FuseSource
>> Web: http://www.fusesource.com
>> Blog: http://willemjiang.blogspot.com (English)
>> http://jnn.javaeye.com (Chinese)
>> Twitter: willemjiang
>> Weibo: willemjiang
>>
>
Re: [DISCUSS] Rebooting ServiceMix 5
Posted by Andreas Pieber <an...@gmail.com>.
Hey Willem,
You can pack Karaf right now into a WAR already and deploy it on an
Tomcat (see [1]).
Kind regards,
Andreas
[1] https://svn.apache.org/repos/asf/karaf/trunk/demos/web/
On Wed, Jun 29, 2011 at 4:18 AM, Willem Jiang <wi...@gmail.com> wrote:
> Hi Guillaume
>
> I just have a simple question for it.
> As you know Karaf is based on OSGi, I don't know how ServiceMix5 can achieve
> this without leverage the OSGi? Do I missing something?
>
> On 6/27/11 11:54 PM, Guillaume Nodet wrote:
>>
>> Additional things that could be pushed inside ServiceMix 5 would be a
>> Tomcat based container deployment
>> option (for those that don't need OSGi), a new manual similar to what
>> we have in Karaf (maybe reusing
>> parts of it).
>
>
> --
> Willem
> ----------------------------------
> FuseSource
> Web: http://www.fusesource.com
> Blog: http://willemjiang.blogspot.com (English)
> http://jnn.javaeye.com (Chinese)
> Twitter: willemjiang
> Weibo: willemjiang
>
Re: [DISCUSS] Rebooting ServiceMix 5
Posted by Willem Jiang <wi...@gmail.com>.
Hi Guillaume
I just have a simple question for it.
As you know Karaf is based on OSGi, I don't know how ServiceMix5 can
achieve this without leverage the OSGi? Do I missing something?
On 6/27/11 11:54 PM, Guillaume Nodet wrote:
> Additional things that could be pushed inside ServiceMix 5 would be a
> Tomcat based container deployment
> option (for those that don't need OSGi), a new manual similar to what
> we have in Karaf (maybe reusing
> parts of it).
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang
Re: [DISCUSS] Rebooting ServiceMix 5
Posted by Juan José Vázquez Delgado <ju...@gmail.com>.
Hi Guillaume,
I´m glad to hear that news.
On the other hand, I´ve seen you are working in the Activiti project
[1] right now [2]. Are there any plans to include the Activiti BPMN
engine in ServiceMix 5?.
BR,
Juanjo.
[1] http://www.activiti.org/
[2] http://www.activiti.org/team.html
On Mon, Jun 27, 2011 at 5:54 PM, Guillaume Nodet <gn...@gmail.com> wrote:
> Last week, I've been discussing with a few committers about the
> ServiceMix roadmap.
> So I'd like to communicate those thoughts to a wider audience.
>
> We've been discussing already that the value of ServiceMix (which was
> the JBI layer in ServiceMix 3
> and the container side in ServiceMix 4) has moved mostly to Camel and
> Karaf respectively. The remainining
> bits are mostly the NMR. However, the value of the NMR is not in the
> NMR itself, but rather the NMR was
> supposed to enable various container-level features. However, we
> haven't really built those features so
> that the *real* value of the NMR is not that high currently.
>
> So, what we've been discussing is to focus on that added value in a
> more transparent way by tweaking
> Camel a bit to support global interceptors, so that one could deploy
> the real routes without having to
> force the use of a specific transport such as the current NMR. This
> way, a user could test / develop
> the Camel routes or take existing Camel routes and deploy them in
> ServiceMix, thereby transparently
> enabling a bunch of useful features. We've been thinking about adding
> message tracing / timing / auditing,
> sending test messages, security checks, viewing flows, persistent
> modification of camel
> routes, camel route versioning, etc... That need to be coupled with a
> web console similar to the
> Camel / ActiveMQ web consoles, to actually display all the data to
> provide useful information for monitoring
> Camel routes and help diagnosing problems in production for example.
> There's really nothing magically new
> here and some of those features were actually part of ServiceMix 3,
> but without much focus on those and
> they have always kept a bit on the side. The idea is really to make
> ServiceMix the best possible container
> for deploying Camel based integration.
>
> Additional things that could be pushed inside ServiceMix 5 would be a
> Tomcat based container deployment
> option (for those that don't need OSGi), a new manual similar to what
> we have in Karaf (maybe reusing
> parts of it). We'd also need a new website (without the technical
> doc, as we have for Karaf I think).
>
> On the maintenance of the JBI components and NMR/JBI layer, I think we
> should keep them in smx4.
> People wanting to deploy those could easily add a pointer to the
> servicemix 4 features descriptors and
> deploy the needed features. So we could officially deprecate those
> and tell users they won't be
> available in smx5. This also means that there's really not much to
> reuse from smx4, so smx5 would
> have its own new and dedicated svn area.
>
> FWIW, I plan to devote a big chunk of my time on ServiceMix 5 in the
> coming months, so those are not
> faithful wishes, but really something I want to start implementing asap.
>
> Feedback welcomed!
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>