Hi,

I have a question about merge the camel-spring and camel-osgi together.
Since camel-osgi have some dependency of the OSGi related jar,

Is it possible to let new merged camel-spring jar live with Non-OSGi environment?

Thanks,

Willem

Claus Ibsen wrote:
On Mon, Sep 7, 2009 at 8:30 AM, Guillaume Nodet<gno...@gmail.com> wrote:
No problems for me.   Though I wonder if this reflects something that have
to be enhanced / modified.   If those jars are so closely related, wouldn't
it make sense to have only one ?  I've already suggested merging
camel-spring and camel-osgi some time ago, but I know wonder if they should
be moved into camel-core directly.  The other fact that leads me this way is
the fact that some components actually depend on camel-spring classes.


No I do not think so. We should keep them separated.

Users of Camel uses Camel in non OSGi environments too.
And non Spring environments as well.

So camel-core should be as light as possible in terms of needed 3rd party .jars.

I only think camel-osgi should be merged to camel-spring if its
possible to use camel-spring with ANY osgi framework .jars at all.
Many users use Camel as just a spring web application.



On Sun, Sep 6, 2009 at 14:33, Claus Ibsen <claus.ib...@gmail.com> wrote:

On Fri, Sep 4, 2009 at 11:53 AM, Willem Jiang<willem.ji...@gmail.com>
wrote:
Because there are some internal API dependencies between the camel-core ,
camel-spring. I'm not sure if the OSGi version range can help us to find
out
the minor internal API change.

Yeah camel-core and camel-spring are really to tightly coupled that
running with different version of them is not recommended.
Eg routing with XML depends on camel-spring where as the routing model
is in camel-core etc.

So it make most sense to support upgrading various other camel
components such as for example camel-jetty, camel-http, camel-velocity
etc.


Willem

Guillaume Nodet wrote:
On Fri, Sep 4, 2009 at 11:22, Willem Jiang <willem.ji...@gmail.com>
wrote:
+1 for #1,

for the #2, I think we could let the component dependent on the version
ranges of camel-core, camel-spring, camel-osgi.
But for camel-core, camel-spring and camel-osgi, they should dependent
each
other with specific version.


Why ?  This would prevent from upgrading one of those bundles without
upgrading the others.


Willem



Guillaume Nodet wrote:

I've spotted a few problems in the way the OSGi metadata for camel
jars
are
computed.
This makes deploying two versions of camel in OSGi nearly impossible.
To fix, I plan to enhance the metadata in two ways:

#1. bundles should not import the packages they export
Here's an example what happen when you do so:
 * install bundle A version vx that export foo.bar and import it
   the OSGi framework will decide that A export this package because
no
other package is available
 * install the same bundle in version vy
   as some of the packages are already exported by the first version
of
A,
the OSGi resolver may choose
   to have this bundle import the package in version vx (provided that
the
version constraints match)
   this means that this bundle will not use its own classes for all
the
packages that are in common, leading
   to obvious problems
So not importing the package means that the OSGi framework will always
use
the classes from inside the bundle.

#2. always use version ranges
 * For non camel imports, I think the default should be to have a
range
equal to [v,v+1) assuming backward compatibility is preserved on minor
releases.  So if one bundle has a dependency on foo.bar version 1.1,
the
range will be [1.1,2) meaning the framework is allowed to choose any
package
with a version >= 1.1 but < 2.0
 * for camel imports, this is a bit trickier.  I think the default
range
should be restricted to minor versions, i.e. [1.1,1.2)

The problem here is to allow someone to update a camel component or
core
without updating the whole camel jars, so we need some flexibility on
this
range.  But usually, I don't think we really ensure full backward
compatibility between minor versions, so having [2.0,3) might not be a
good
idea.
Furthermore, this would mean that you can't really deploy two
different
minor versions of camel in the same framework, which I think is
desirable.

Now, the tricky part is to make sure that we always use consistent
classes.
For example when camel-core discover a component, we don't really want
camel-core 1.4 discovering camel 2.0 components, as this would fail.
So
the discovery mechanism has to be enhanced to make sure we load
compatible
classes.
In OSGi, this can be done by loading a class from the component bundle
and
making sure it's the same as our.
For example:
  componentBundle.loadClass(org.apache.camel.Endpoint.class.getName())
==
org.apache.camel.Endpoint.class
This way, the discovery mechanism will be retricted to components that
are
actually wired to this camel-core bundle.

So at the end we should be able to:
 * deploy multiple versions of camel, provided they have different
minor
releases (ex: 1.4, 2.0, 2.1)
 * upgrade components / core with micro release (ex: camel-core 2.0,
camel-spring 2.0.2, camel-atom 2.0.1)
And everything should work nicely :-)

I'll start updating the OSGi metadata, but any help would be welcome,
as
there are tons of components here !
Also, any volunteer for upgrading and testing the discovery mechanism
is
welcomed !






--
Claus Ibsen
Apache Camel Committer

Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus



--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com





Reply via email to