Mailing-List: contact dev-help@karaf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@karaf.apache.org
Received-SPF: pass (nike.apache.org: domain of anpieber@gmail.com designates
 209.85.214.48 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=date:from:to:subject:message-id:references:mime-version
         :content-type:content-disposition:in-reply-to:user-agent;
        b=bN44tnpFqmDP5h7nducTF9wuCH8qb85Z8r2FTSOw6mCGqHX749qLnXnpLHzDNYn/az
         xw1H4EB+eGYUh8Q3kVLEm/lp1GsTDM+R0dYOrY06DY4yG0wFwVbkMZk43br8jrHjlWF4
         vnm3d8avd4CW6BF3S1EOKsgMGZ4Bx+XaK/V6A=
Date: Fri, 4 Feb 2011 04:34:33 +0100
From: Andreas Pieber <anpieber@gmail.com>
To: dev@karaf.apache.org
Subject: Re: Thoughts about Karaf profiles / releases / growing number of
 dependencies (Re: AW: AW: Problem when starting camel-cxf in karaf)
Message-ID: <20110204033433.GK32166@coprime.kabsi.at>
References: <AANLkTi=sUbhFnvf9cQEDJh9pXN8yr3xRK1Lj+UyPfVE0@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="ogUXNSQj4OI1q3LQ"
Content-Disposition: inline
In-Reply-To: <AANLkTi=sUbhFnvf9cQEDJh9pXN8yr3xRK1Lj+UyPfVE0@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)

--ogUXNSQj4OI1q3LQ
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

OK, there are many points in my head about this for some time now and I hop=
e I
get them out straight here. If I'm not able to make any of my points clear =
don't
hesitate to ask :)

First of all I'm completely with Guillaume. I don't like the way Karaf blows
up. We have a standard and an enterprise distribution and a minimal distrib=
ution
and in future one for android... STOP. I think this is not the way Karaf sh=
ould go.

In addition, tbh I also don't like the way client projects (such as smx) ha=
ve to
tweak Karaf around to make it runnable. This makes everything complex and n=
ot
easy to use understand/start with.

Next I think the root of all evil are our configuration files. The need tha=
t we
have to tweak system.properties, custom.properties, jre.properties,
org...features.cfg to get a running, custom distribution. This does not feel
right.

Fourth: I don't like that we need to use our own maven plugins to build Kar=
af is
IMHO a sign that Karaf is becoming much too big...

Last but not least, I hate that I have to google for all those feature urls=
=20
and collect them locally to not forgetting them :)

OK, so far to the problems. According to the mails I've read by now I think=
 I'm
not the only one aware of those problems :) --> I would propose some roadmap
to get this straight again:

1) branch off karaf-2.x branch now (independent of the missing versions) and
stay as it is now. Some ppl already depend on karaf-2.1.99-SNAPSHOT and I d=
on't
think that we'll make friends if we make any drastically changes to this
version.

2) Start developing karaf-2.99.99-SNAPSHOT right now.

3) As a first step I think we should add something like an online registry =
to
Karaf where feature files could be found. E.g. something like
karaf.apache.org/registry.xml. This would allow us to make Karaf behave the=
 same
without having to pack everything together during assembly phase. Here it m=
ay
also help to add a features:addregistryurl command allowing clients to host
their own registries.

4) Move enterprise.features.xml into aries project, split standard.features=
=2Exml
into the different projects: karaf-obr, karaf-ssh, ops4j-web (e.g. with jet=
ty),
spring2, spring3, ... and create own projects for the additional components=
=2E I'm
with Jamie that this will complex the release process, but IMHO everything =
we
create features files for shouldn't be in the core. As said somehow I even =
don't
like that we have features.xml in the core at all. All those features.xml h=
ave
to be added to the registry. This way we could guarantee that Karaf still
behaves the same although we've reduced the core packages/repo/distribution.

5) We have to extend the kar/features.xml model drastically adding variation
points for the different configuration possibilities in Karaf. E.g. we need=
 a
variation point for lib, jre.properties, etc/(to add additional property fi=
les),
system (where we drop additional .jre bundles, ...), brandings, ... With th=
at some variation
points require Karaf to reboot (we couldn't change everything at runtime). =
Which
means we have to cache the changes and apply them on reboot. In addition I =
know
that there will be some pain in config file merging, but I think this will =
be
worth the effort.

6) Now that we've removed all the specific things from Karaf we can reduce =
the
build process completely to one minimal distribution of Karaf (at maximum o=
ne
additional for android?!) without using the features concepts directly in t=
he
kernel. This will also allow us to develop the karaf-maven-plugin directly =
in
the kernel without the burden of forking the process anywhere.

7) I think by that we're almost finished now. We can start contributing
features/kar packages for cxf, apache ds, camel, ... and add them again to =
the
registry. For this process the karaf-maven-plugin could/should be used.

8) Now a user will first of all create its own kar/features which tweak the
kernel as required. Finally he can either provide the kar/features bundle o=
nly.
The assembly process will (and should) always look like (reduced):

karaf-maven-plugin
execution: distribution
kar-list (branding, docs, ... everything is a kar file, nothing more here)

IMHO with all of this we can finally provide only one very small distributi=
on.
Someone only experimenting/developing can do a=20

features:install war, cfx, ds
admin:reboot

Everyone else can create distributions as he likes.

OK, I know that not all of those points are new or exclusively by me, some =
go a
little bit a different direction than discussed by now and not all of them =
are
nailed down to the latest detail (by now). Please don't flame me because of=
 this;
I know that this is not the only way to go but it somehow feels right to me=
 :)

so... wdyt?

kind regards,
andreas

On Fri, Feb 04, 2011 at 12:07:42AM +0100, Guillaume Nodet wrote:
> Yeah, the problem is that Karaf itself isn't a container for Camel or
> CXF and we have some users that just want to plain JRE without any
> tweaks for running SAAJ because they don't care.
> ServiceMix on the other hand is dedicated to host such applications,
> so that's why the default config works better.
> I'm ok with the idea of profiles in karaf, but we need to make sure we
> don't end up with having to include and depend on all apache projects,
> as Karaf itself has imho no purpose of becoming a default distribution
> of CXF, Camel, ActiveMQ, Directory, etc...
> I think each project could easily provide a karaf features so that
> they would easily be deployed in a bare Karaf, but at some point, it
> does not really scale nor make sense to put everything back into
> Karaf.
>=20
> Tweaking the system properties is sometimes needed depending on what
> you need to deploy, because OSGi is lacking on certain areas (or
> because the JVM isn't really modular, depending on how you see
> things).  Some people are happy with using the JAXB implementation
> from the JVM without being able to change it easily, some people may
> want to be able to deploy those as OSGi bundles.  Karaf can't do both
> at the same time.
>=20
> Another point, is that the amount of third party dependencies is
> becoming increasingly important in Karaf, and that's really becoming a
> problem for simply releasing Karaf in an efficient manner.
> So I'm tempted to say that we should push back on those projects and
> have them provide karaf features, rather than having karaf providing
> features for those.  I'm mostly thinking here about pax-web and the
> war support (which is really cool, no doubt on that) and aries and
> support for things we don't embed by default (jpa, etc..).
>=20
> I certainly don't have a good answer yet, but I just want to make sure
> everyone is aware of the potential problem.
>=20
> If we keep adding dependencies, our release cycles will necessarily be
> longer and longer ....  For example camel has a release cycle of one
> minor version every few months, ServiceMix even less, while CXF has
> much less external dependencies and manage to keep a high frequency of
> releases.  2.2 could have been shipped early december, but we were
> waiting for aries.  Now aries has been released, but we still have
> some snapshots dependencies on some felix or ops4j components.  And
> we've added stuff that's not completely stabilized.
>=20
> Once again, I'm just trying to state facts so that everybody
> understand the situation.  I'm personnaly not really happy that the
> 2.2 release is planned since 2 months but still can't get out and I
> think it clearly means that we're going in a wrong direction somehow
> ....
>=20
> Sorry for the rant.  There are a bunch of unrelated things here, ...
>=20
> On Wed, Feb 2, 2011 at 11:29, Jean-Baptiste Onofr=E9 <jb@nanthrax.net> wr=
ote:
> > Claus already raised a Jira about that.
> >
> > Guillaume wasn't very ok to set the jre.properties by default.
> >
> > On the other hand, I launched a discussion thread about Karaf profiles.=
 It's
> > typically the kind of tuning which is part of a profiles.
> >
> > Waiting for the profiles design, we can provide a Karaf Enterprise
> > distribution including this kind of tuning related to Camel/CXF/SMX.
> >
> > I add Karaf dev mailing list to see what the team says :)
> >
> > Regards
> > JB
> >
> > On 02/02/2011 11:21 AM, Christian Schneider wrote:
> >>
> >> Are these adapted jre.properties only usefull for Servicemix and the
> >> Talend Service Factory or do you think it would make sense to change t=
hem in
> >> the karaf distribution.
> >>
> >> Best regards
> >>
> >> Christian
> >>
> >>
> >> -----Urspr=FCngliche Nachricht-----
> >> Von: Jean-Baptiste Onofr=E9 [mailto:jb@nanthrax.net]
> >> Gesendet: Mittwoch, 2. Februar 2011 11:02
> >> An: users@camel.apache.org
> >> Betreff: Re: AW: Problem when starting camel-cxf in karaf
> >>
> >> Yeah, you can take a look on the ServiceMix one too :)
> >>
> >> Regards
> >> JB
> >>
> >> On 02/02/2011 10:26 AM, Christian Schneider wrote:
> >>>
> >>> I think I was able to solve the problem. I had to change the
> >>> jre.properties to exclude some packages from the system bundle export.
> >>> The jre.properties from the Talend Service Factory seem to work:
> >>>
> >>> http://de.talend.com/products-application-integration/talend-service-=
factory-community-edition.php
> >>>
> >>> Christian
> >>>
> >>>
> >>> -----Urspr=FCngliche Nachricht-----
> >>> Von: Christian Schneider [mailto:cschneider@talend.com]
> >>> Gesendet: Mittwoch, 2. Februar 2011 09:52
> >>> An: users@camel.apache.org
> >>> Betreff: Problem when starting camel-cxf in karaf
> >>>
> >>> Hi all,
> >>>
> >>> I am trying to run Apache Camel (feature camel-cxf) in Apache Karaf.
> >>>
> >>> I am using a fresh Karaf 2.1.3 download.
> >>> I start karaf and enter:
> >>>
> >>>> features:addurl
> >>>> mvn:org.apache.camel.karaf/apache-camel/2.6.0/xml/features
> >>>> features:install camel-cxf
> >>>
> >>> I get an exception while starting
> >>> org.apache.servicemix.bundles.saaj-impl:
> >>> Unable to resolve 97.0: missing requirement [97.0] package;
> >>> (package=3Dcom.sun.org.apache.xerces.internal.dom)
> >>>
> >>> Any idea what I am doing wrong?
> >>>
> >>> Christian
> >>>
> >>> ----------------------
> >>>
> >>> 02.02.2011 09:46:08 org.apache.karaf.main.SimpleFileLock lock
> >>> INFO: locking
> >>> 09:46:09,765 | INFO =A0| FelixStartLevel =A0| jmx
> >>> =A0| ? =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 ? | 20 - org.apache.aries.jmx -
> >>> 0.2.0.incubating | Starting JMX OSGi agent
> >>> 09:46:09,781 | INFO =A0| FelixStartLevel =A0| jmx
> >>> =A0| ? =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 ? | 20 - org.apache.aries.jmx -
> >>> 0.2.0.incubating | Registering MBean with ObjectName
> >>> [osgi.compendium:service=3Dcm,version=3D1.3] for service with service=
=2Eid [10]
> >>> 09:46:09,796 | WARN =A0| rint Extender: 3 | BlueprintContainerImpl
> >>> =A0 | container.BlueprintContainerImpl =A0252 | 7 - org.apache.aries.=
blueprint -
> >>> 0.2.0.incubating | Bundle org.apache.karaf.features.command is waitin=
g for
> >>> namespace handlers
> >>> [(&(objectClass=3Dorg.apache.aries.blueprint.NamespaceHandler)(osgi.s=
ervice.blueprint.namespace=3Dhttp://karaf.apache.org/xmlns/shell/v1.0.0))]
> >>> 09:46:09,796 | WARN =A0| rint Extender: 2 | BlueprintContainerImpl
> >>> =A0 | container.BlueprintContainerImpl =A0252 | 7 - org.apache.aries.=
blueprint -
> >>> 0.2.0.incubating | Bundle org.apache.karaf.shell.osgi is waiting for
> >>> namespace handlers
> >>> [(&(objectClass=3Dorg.apache.aries.blueprint.NamespaceHandler)(osgi.s=
ervice.blueprint.namespace=3Dhttp://karaf.apache.org/xmlns/shell/v1.0.0))]
> >>> 09:46:09,796 | WARN =A0| JMX OSGi Agent =A0 | jmx
> >>> =A0| ? =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 ? | 20 - org.apache.aries.jmx -
> >>> 0.2.0.incubating | There are no MBean servers registred, can't regist=
er
> >>> MBeans
> >>> 09:46:09,890 | WARN =A0| rint Extender: 2 | BlueprintContainerImpl
> >>> =A0 | container.BlueprintContainerImpl =A0252 | 7 - org.apache.aries.=
blueprint -
> >>> 0.2.0.incubating | Bundle org.apache.karaf.shell.console is waiting f=
or
> >>> namespace handlers
> >>> [(&(objectClass=3Dorg.apache.aries.blueprint.NamespaceHandler)(osgi.s=
ervice.blueprint.namespace=3Dhttp://aries.apache.org/blueprint/xmlns/bluepr=
int-ext/v1.0.0))]
> >>> 09:46:09,968 | WARN =A0| rint Extender: 2 | BlueprintContainerImpl
> >>> =A0 | container.BlueprintContainerImpl =A0252 | 7 - org.apache.aries.=
blueprint -
> >>> 0.2.0.incubating | Bundle org.apache.karaf.shell.dev is waiting for
> >>> namespace handlers
> >>> [(&(objectClass=3Dorg.apache.aries.blueprint.NamespaceHandler)(osgi.s=
ervice.blueprint.namespace=3Dhttp://karaf.apache.org/xmlns/shell/v1.0.0))]
> >>> 09:46:10,218 | WARN =A0| rint Extender: 3 | BlueprintContainerImpl
> >>> =A0 | container.BlueprintContainerImpl =A0252 | 7 - org.apache.aries.=
blueprint -
> >>> 0.2.0.incubating | Bundle org.apache.karaf.shell.ssh is waiting for
> >>> namespace handlers
> >>> [(&(objectClass=3Dorg.apache.aries.blueprint.NamespaceHandler)(osgi.s=
ervice.blueprint.namespace=3Dhttp://karaf.apache.org/xmlns/shell/v1.0.0))]
> >>> 09:46:10,234 | WARN =A0| rint Extender: 3 | BlueprintContainerImpl
> >>> =A0 | container.BlueprintContainerImpl =A0252 | 7 - org.apache.aries.=
blueprint -
> >>> 0.2.0.incubating | Bundle org.apache.karaf.admin.command is waiting f=
or
> >>> namespace handlers
> >>> [(&(objectClass=3Dorg.apache.aries.blueprint.NamespaceHandler)(osgi.s=
ervice.blueprint.namespace=3Dhttp://karaf.apache.org/xmlns/shell/v1.0.0))]
> >>> 09:46:10,250 | WARN =A0| rint Extender: 3 | BlueprintContainerImpl
> >>> =A0 | container.BlueprintContainerImpl =A0252 | 7 - org.apache.aries.=
blueprint -
> >>> 0.2.0.incubating | Bundle org.apache.karaf.shell.commands is waiting =
for
> >>> namespace handlers
> >>> [(&(objectClass=3Dorg.apache.aries.blueprint.NamespaceHandler)(osgi.s=
ervice.blueprint.namespace=3Dhttp://karaf.apache.org/xmlns/shell/v1.0.0))]
> >>> 09:46:10,375 | WARN =A0| rint Extender: 2 | BlueprintContainerImpl
> >>> =A0 | container.BlueprintContainerImpl =A0252 | 7 - org.apache.aries.=
blueprint -
> >>> 0.2.0.incubating | Bundle org.apache.karaf.shell.packages is waiting =
for
> >>> namespace handlers
> >>> [(&(objectClass=3Dorg.apache.aries.blueprint.NamespaceHandler)(osgi.s=
ervice.blueprint.namespace=3Dhttp://karaf.apache.org/xmlns/shell/v1.0.0))]
> >>> 09:46:11,609 | INFO =A0| Thread-5 =A0 =A0 =A0 =A0 | FeaturesServiceIm=
pl
> >>> =A0| res.internal.FeaturesServiceImpl =A0293 | 19 -
> >>> org.apache.karaf.features.core - 2.1.3 | Bundles to refresh:
> >>> 09:46:11,640 | INFO =A0| rint Extender: 3 | SecurityUtils
> >>> =A0| e.sshd.common.util.SecurityUtils =A0 80 | 25 - sshd-core - 0.4.0=
 |
> >>> BouncyCastle not registered, using the default JCE provider
> >>> 09:46:11,968 | INFO =A0| JMX OSGi Agent =A0 | jmx
> >>> =A0| ? =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 ? | 20 - org.apache.aries.jmx -
> >>> 0.2.0.incubating | Registering org.osgi.jmx.framework.BundleStateMBea=
n to
> >>> MBeanServer com.sun.jmx.mbeanserver.JmxMBeanServer@6e3d60 with name
> >>> osgi.core:type=3DbundleState,version=3D1.5
> >>> 09:46:12,000 | INFO =A0| JMX OSGi Agent =A0 | jmx
> >>> =A0| ? =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 ? | 20 - org.apache.aries.jmx -
> >>> 0.2.0.incubating | Registering org.osgi.jmx.framework.ServiceStateMBe=
an to
> >>> MBeanServer com.sun.jmx.mbeanserver.JmxMBeanServer@6e3d60 with name
> >>> osgi.core:type=3DserviceState,version=3D1.5
> >>> 09:46:12,000 | INFO =A0| JMX OSGi Agent =A0 | jmx
> >>> =A0| ? =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 ? | 20 - org.apache.aries.jmx -
> >>> 0.2.0.incubating | Registering org.osgi.jmx.framework.FrameworkMBean =
to
> >>> MBeanServer com.sun.jmx.mbeanserver.JmxMBeanServer@6e3d60 with name
> >>> osgi.core:type=3Dframework,version=3D1.5
> >>> 09:46:12,031 | INFO =A0| JMX OSGi Agent =A0 | jmx
> >>> =A0| ? =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 ? | 20 - org.apache.aries.jmx -
> >>> 0.2.0.incubating | Registering
> >>> org.osgi.jmx.service.cm.ConfigurationAdminMBean to MBeanServer
> >>> com.sun.jmx.mbeanserver.JmxMBeanServer@6e3d60 with name
> >>> osgi.compendium:service=3Dcm,version=3D1.3
> >>> 09:46:12,031 | INFO =A0| JMX OSGi Agent =A0 | jmx
> >>> =A0| ? =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 ? | 20 - org.apache.aries.jmx -
> >>> 0.2.0.incubating | Registering org.osgi.jmx.framework.PackageStateMBe=
an to
> >>> MBeanServer com.sun.jmx.mbeanserver.JmxMBeanServer@6e3d60 with name
> >>> osgi.core:type=3DpackageState,version=3D1.5
> >>> 09:48:08,234 | INFO =A0| l Console Thread | FeaturesServiceImpl
> >>> =A0| res.internal.FeaturesServiceImpl =A0293 | 19 -
> >>> org.apache.karaf.features.core - 2.1.3 | Bundles to refresh:
> >>> 09:48:08,656 | INFO =A0| l Console Thread | ContextLoaderListener
> >>> =A0| .activator.ContextLoaderListener =A0356 | 44 -
> >>> org.springframework.osgi.extender - 1.2.0 | Starting
> >>> [org.springframework.osgi.extender] bundle v.[1.2.0]
> >>> 09:48:08,781 | INFO =A0| l Console Thread | ExtenderConfiguration
> >>> =A0| al.support.ExtenderConfiguration =A0150 | 44 -
> >>> org.springframework.osgi.extender - 1.2.0 | No custom extender config=
uration
> >>> detected; using defaults...
> >>> 09:48:08,781 | INFO =A0| l Console Thread | TimerTaskExecutor
> >>> =A0| heduling.timer.TimerTaskExecutor =A0106 | 38 - org.springframewo=
rk.context
> >>> - 3.0.5.RELEASE | Initializing Timer
> >>> 09:48:09,281 | INFO =A0| l Console Thread | Activator
> >>> =A0| apache.camel.impl.osgi.Activator =A0 83 | 51 - org.apache.camel.=
camel-core
> >>> - 2.6.0 | Camel activator starting
> >>> 09:48:09,312 | INFO =A0| l Console Thread | Activator
> >>> =A0| apache.camel.impl.osgi.Activator =A0 86 | 51 - org.apache.camel.=
camel-core
> >>> - 2.6.0 | Camel activator started
> >>> 09:48:10,968 | INFO =A0| l Console Thread | Activator
> >>> =A0| apache.camel.impl.osgi.Activator =A0 90 | 51 - org.apache.camel.=
camel-core
> >>> - 2.6.0 | Camel activator stopping
> >>> 09:48:10,968 | INFO =A0| l Console Thread | Activator
> >>> =A0| apache.camel.impl.osgi.Activator =A0 92 | 51 - org.apache.camel.=
camel-core
> >>> - 2.6.0 | Camel activator stopped
> >>> 09:48:11,984 | INFO =A0| l Console Thread | ContextLoaderListener
> >>> =A0| .activator.ContextLoaderListener =A0449 | 44 -
> >>> org.springframework.osgi.extender - 1.2.0 | Stopping
> >>> [org.springframework.osgi.extender] bundle v.[1.2.0]
> >>> 09:48:11,984 | INFO =A0| l Console Thread | TimerTaskExecutor
> >>> =A0| heduling.timer.TimerTaskExecutor =A0179 | 38 - org.springframewo=
rk.context
> >>> - 3.0.5.RELEASE | Cancelling Timer
> >>> 09:48:12,281 | INFO =A0| l Console Thread | Console
> >>> =A0| araf.shell.console.jline.Console =A0188 | 11 -
> >>> org.apache.karaf.shell.console - 2.1.3 | Exception caught while execu=
ting
> >>> command
> >>> java.lang.Exception: Could not start bundle
> >>> mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.saaj-=
impl/1.3.2_1
> >>> in feature(s) camel-cxf-2.6.0: Unresolved constraint in bundle
> >>> org.apache.servicemix.bundles.saaj-impl [97]: Unable to resolve 97.0:
> >>> missing requirement [97.0] package;
> >>> (package=3Dcom.sun.org.apache.xerces.internal.dom)
> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0at
> >>> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature=
s(FeaturesServiceImpl.java:326)[19:org.apache.karaf.features.core:2.1.3]
> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0at
> >>> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature=
(FeaturesServiceImpl.java:254)[19:org.apache.karaf.features.core:2.1.3]
> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0at
> >>> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature=
(FeaturesServiceImpl.java:250)[19:org.apache.karaf.features.core:2.1.3]
> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0at
> >>> org.apache.karaf.features.command.InstallFeatureCommand.doExecute(Ins=
tallFeatureCommand.java:51)[9:org.apache.karaf.features.command:2.1.3]
> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0at
> >>> org.apache.karaf.features.command.FeaturesCommandSupport.doExecute(Fe=
aturesCommandSupport.java:39)[9:org.apache.karaf.features.command:2.1.3]
> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0at
> >>> org.apache.karaf.shell.console.OsgiCommandSupport.execute(OsgiCommand=
Support.java:38)[11:org.apache.karaf.shell.console:2.1.3]
> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0at
> >>> org.apache.felix.gogo.commands.basic.AbstractCommand.execute(Abstract=
Command.java:35)[11:org.apache.karaf.shell.console:2.1.3]
> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0at
> >>> org.apache.felix.gogo.runtime.shell.CommandProxy.execute(CommandProxy=
=2Ejava:50)[11:org.apache.karaf.shell.console:2.1.3]
> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0at
> >>> org.apache.felix.gogo.runtime.shell.Closure.execute(Closure.java:229)=
[11:org.apache.karaf.shell.console:2.1.3]
> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0at
> >>> org.apache.felix.gogo.runtime.shell.Closure.executeStatement(Closure.=
java:162)[11:org.apache.karaf.shell.console:2.1.3]
> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0at
> >>> org.apache.felix.gogo.runtime.shell.Pipe.run(Pipe.java:101)[11:org.ap=
ache.karaf.shell.console:2.1.3]
> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0at
> >>> org.apache.felix.gogo.runtime.shell.Closure.execute(Closure.java:79)[=
11:org.apache.karaf.shell.console:2.1.3]
> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0at
> >>> org.apache.felix.gogo.runtime.shell.CommandSessionImpl.execute(Comman=
dSessionImpl.java:71)[11:org.apache.karaf.shell.console:2.1.3]
> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0at
> >>> org.apache.karaf.shell.console.jline.Console.run(Console.java:170)[11=
:org.apache.karaf.shell.console:2.1.3]
> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0at java.lang.Thread.run(Thread.jav=
a:662)[:1.6.0_23]
> >>> Caused by: org.osgi.framework.BundleException: Unresolved constraint =
in
> >>> bundle org.apache.servicemix.bundles.saaj-impl [97]: Unable to resolv=
e 97.0:
> >>> missing requirement [97.0] package;
> >>> (package=3Dcom.sun.org.apache.xerces.internal.dom)
> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0at
> >>> org.apache.felix.framework.Felix.resolveBundle(Felix.java:3409)[org.a=
pache.felix.framework-3.0.2.jar:]
> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0at
> >>> org.apache.felix.framework.Felix.startBundle(Felix.java:1709)[org.apa=
che.felix.framework-3.0.2.jar:]
> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0at
> >>> org.apache.felix.framework.BundleImpl.start(BundleImpl.java:905)[org.=
apache.felix.framework-3.0.2.jar:]
> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0at
> >>> org.apache.felix.framework.BundleImpl.start(BundleImpl.java:892)[org.=
apache.felix.framework-3.0.2.jar:]
> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0at
> >>> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature=
s(FeaturesServiceImpl.java:323)[19:org.apache.karaf.features.core:2.1.3]
> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0... 14 more
> >>>
> >
>=20
>=20
>=20
> --=20
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com

--ogUXNSQj4OI1q3LQ
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJNS3PJAAoJEIPi9q1XSsGWXR8P/3xcGxTQDg5B8sh0asSpCFy1
nbr4NlPzjw+YrL032LEiNYxtJYXwpod1zraA2ZTu/bLz3tnSU+E0CTKiBgQ9LMPC
QnUVKOXaoFqQSSLEelKurYtoUiePI9v53T9UZDYTfq+IlFlUl/w26cc+GX2XRWmO
Dz8gi4xG3LUm0qE/rVZh+JQ28ALT/8w6e9EyNlDDmT6BGUQYRMczdzgjGVCko3iy
2Xi4oB5WXstH6HcgyOzw62DZk7NXK6N/Po1ax/TABqAr70PZs4S3WoM7K/Gydsvc
b0lEzyEyEZrYqhUw74EOkUnJzqTLlTD5MsGmDFl5FHPkFvpX57C/10pju0Al7Vh9
xH4qkcKqw4amBRfh0AaxZ2GwojIswoPQoBphvNo5SlTuMkr5U/detts4HzD77kZO
912FqZ9GS1hLc4EEvtNRZsW6I3o4b/sc77yJHKmzCG9eIqTF+pLBLIulWplez9S3
Stvc5udhUcvGkL2/YPQXdQjNd9SEeUOuoq5/b8G7Oi+phFKQoQmuRgrsYuWBfb68
EQqQMJNUVuNxsAZsXPvsucaPxmn1aqx+ipuSbGUhKuvYe9rBNqFmUH8tosTS+16Z
N50iHgfYL+AKPXjMFVzI789w7LRzypJhUkZZHJpJ1DYd8CmkTPWlkcD6y0EXvbNb
MaITqJW8TMjAl046Dshy
=dsiK
-----END PGP SIGNATURE-----

--ogUXNSQj4OI1q3LQ--