You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by Guillaume Nodet <gn...@gmail.com> on 2011/02/04 00:07:42 UTC
Thoughts about Karaf profiles / releases / growing number of
dependencies (Re: AW: AW: Problem when starting camel-cxf in karaf)
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.
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.
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..).
I certainly don't have a good answer yet, but I just want to make sure
everyone is aware of the potential problem.
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.
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
....
Sorry for the rant. There are a bunch of unrelated things here, ...
On Wed, Feb 2, 2011 at 11:29, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> 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 them in
>> the karaf distribution.
>>
>> Best regards
>>
>> Christian
>>
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Jean-Baptiste Onofré [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üngliche 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=com.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 | FelixStartLevel | jmx
>>> | ? ? | 20 - org.apache.aries.jmx -
>>> 0.2.0.incubating | Starting JMX OSGi agent
>>> 09:46:09,781 | INFO | FelixStartLevel | jmx
>>> | ? ? | 20 - org.apache.aries.jmx -
>>> 0.2.0.incubating | Registering MBean with ObjectName
>>> [osgi.compendium:service=cm,version=1.3] for service with service.id [10]
>>> 09:46:09,796 | WARN | rint Extender: 3 | BlueprintContainerImpl
>>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
>>> 0.2.0.incubating | Bundle org.apache.karaf.features.command is waiting for
>>> namespace handlers
>>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
>>> 09:46:09,796 | WARN | rint Extender: 2 | BlueprintContainerImpl
>>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
>>> 0.2.0.incubating | Bundle org.apache.karaf.shell.osgi is waiting for
>>> namespace handlers
>>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
>>> 09:46:09,796 | WARN | JMX OSGi Agent | jmx
>>> | ? ? | 20 - org.apache.aries.jmx -
>>> 0.2.0.incubating | There are no MBean servers registred, can't register
>>> MBeans
>>> 09:46:09,890 | WARN | rint Extender: 2 | BlueprintContainerImpl
>>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
>>> 0.2.0.incubating | Bundle org.apache.karaf.shell.console is waiting for
>>> namespace handlers
>>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0))]
>>> 09:46:09,968 | WARN | rint Extender: 2 | BlueprintContainerImpl
>>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
>>> 0.2.0.incubating | Bundle org.apache.karaf.shell.dev is waiting for
>>> namespace handlers
>>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
>>> 09:46:10,218 | WARN | rint Extender: 3 | BlueprintContainerImpl
>>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
>>> 0.2.0.incubating | Bundle org.apache.karaf.shell.ssh is waiting for
>>> namespace handlers
>>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
>>> 09:46:10,234 | WARN | rint Extender: 3 | BlueprintContainerImpl
>>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
>>> 0.2.0.incubating | Bundle org.apache.karaf.admin.command is waiting for
>>> namespace handlers
>>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
>>> 09:46:10,250 | WARN | rint Extender: 3 | BlueprintContainerImpl
>>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
>>> 0.2.0.incubating | Bundle org.apache.karaf.shell.commands is waiting for
>>> namespace handlers
>>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
>>> 09:46:10,375 | WARN | rint Extender: 2 | BlueprintContainerImpl
>>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
>>> 0.2.0.incubating | Bundle org.apache.karaf.shell.packages is waiting for
>>> namespace handlers
>>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
>>> 09:46:11,609 | INFO | Thread-5 | FeaturesServiceImpl
>>> | res.internal.FeaturesServiceImpl 293 | 19 -
>>> org.apache.karaf.features.core - 2.1.3 | Bundles to refresh:
>>> 09:46:11,640 | INFO | rint Extender: 3 | SecurityUtils
>>> | e.sshd.common.util.SecurityUtils 80 | 25 - sshd-core - 0.4.0 |
>>> BouncyCastle not registered, using the default JCE provider
>>> 09:46:11,968 | INFO | JMX OSGi Agent | jmx
>>> | ? ? | 20 - org.apache.aries.jmx -
>>> 0.2.0.incubating | Registering org.osgi.jmx.framework.BundleStateMBean to
>>> MBeanServer com.sun.jmx.mbeanserver.JmxMBeanServer@6e3d60 with name
>>> osgi.core:type=bundleState,version=1.5
>>> 09:46:12,000 | INFO | JMX OSGi Agent | jmx
>>> | ? ? | 20 - org.apache.aries.jmx -
>>> 0.2.0.incubating | Registering org.osgi.jmx.framework.ServiceStateMBean to
>>> MBeanServer com.sun.jmx.mbeanserver.JmxMBeanServer@6e3d60 with name
>>> osgi.core:type=serviceState,version=1.5
>>> 09:46:12,000 | INFO | JMX OSGi Agent | jmx
>>> | ? ? | 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=framework,version=1.5
>>> 09:46:12,031 | INFO | JMX OSGi Agent | jmx
>>> | ? ? | 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=cm,version=1.3
>>> 09:46:12,031 | INFO | JMX OSGi Agent | jmx
>>> | ? ? | 20 - org.apache.aries.jmx -
>>> 0.2.0.incubating | Registering org.osgi.jmx.framework.PackageStateMBean to
>>> MBeanServer com.sun.jmx.mbeanserver.JmxMBeanServer@6e3d60 with name
>>> osgi.core:type=packageState,version=1.5
>>> 09:48:08,234 | INFO | l Console Thread | FeaturesServiceImpl
>>> | res.internal.FeaturesServiceImpl 293 | 19 -
>>> org.apache.karaf.features.core - 2.1.3 | Bundles to refresh:
>>> 09:48:08,656 | INFO | l Console Thread | ContextLoaderListener
>>> | .activator.ContextLoaderListener 356 | 44 -
>>> org.springframework.osgi.extender - 1.2.0 | Starting
>>> [org.springframework.osgi.extender] bundle v.[1.2.0]
>>> 09:48:08,781 | INFO | l Console Thread | ExtenderConfiguration
>>> | al.support.ExtenderConfiguration 150 | 44 -
>>> org.springframework.osgi.extender - 1.2.0 | No custom extender configuration
>>> detected; using defaults...
>>> 09:48:08,781 | INFO | l Console Thread | TimerTaskExecutor
>>> | heduling.timer.TimerTaskExecutor 106 | 38 - org.springframework.context
>>> - 3.0.5.RELEASE | Initializing Timer
>>> 09:48:09,281 | INFO | l Console Thread | Activator
>>> | apache.camel.impl.osgi.Activator 83 | 51 - org.apache.camel.camel-core
>>> - 2.6.0 | Camel activator starting
>>> 09:48:09,312 | INFO | l Console Thread | Activator
>>> | apache.camel.impl.osgi.Activator 86 | 51 - org.apache.camel.camel-core
>>> - 2.6.0 | Camel activator started
>>> 09:48:10,968 | INFO | l Console Thread | Activator
>>> | apache.camel.impl.osgi.Activator 90 | 51 - org.apache.camel.camel-core
>>> - 2.6.0 | Camel activator stopping
>>> 09:48:10,968 | INFO | l Console Thread | Activator
>>> | apache.camel.impl.osgi.Activator 92 | 51 - org.apache.camel.camel-core
>>> - 2.6.0 | Camel activator stopped
>>> 09:48:11,984 | INFO | l Console Thread | ContextLoaderListener
>>> | .activator.ContextLoaderListener 449 | 44 -
>>> org.springframework.osgi.extender - 1.2.0 | Stopping
>>> [org.springframework.osgi.extender] bundle v.[1.2.0]
>>> 09:48:11,984 | INFO | l Console Thread | TimerTaskExecutor
>>> | heduling.timer.TimerTaskExecutor 179 | 38 - org.springframework.context
>>> - 3.0.5.RELEASE | Cancelling Timer
>>> 09:48:12,281 | INFO | l Console Thread | Console
>>> | araf.shell.console.jline.Console 188 | 11 -
>>> org.apache.karaf.shell.console - 2.1.3 | Exception caught while executing
>>> 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=com.sun.org.apache.xerces.internal.dom)
>>> at
>>> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeatures(FeaturesServiceImpl.java:326)[19:org.apache.karaf.features.core:2.1.3]
>>> at
>>> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(FeaturesServiceImpl.java:254)[19:org.apache.karaf.features.core:2.1.3]
>>> at
>>> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(FeaturesServiceImpl.java:250)[19:org.apache.karaf.features.core:2.1.3]
>>> at
>>> org.apache.karaf.features.command.InstallFeatureCommand.doExecute(InstallFeatureCommand.java:51)[9:org.apache.karaf.features.command:2.1.3]
>>> at
>>> org.apache.karaf.features.command.FeaturesCommandSupport.doExecute(FeaturesCommandSupport.java:39)[9:org.apache.karaf.features.command:2.1.3]
>>> at
>>> org.apache.karaf.shell.console.OsgiCommandSupport.execute(OsgiCommandSupport.java:38)[11:org.apache.karaf.shell.console:2.1.3]
>>> at
>>> org.apache.felix.gogo.commands.basic.AbstractCommand.execute(AbstractCommand.java:35)[11:org.apache.karaf.shell.console:2.1.3]
>>> at
>>> org.apache.felix.gogo.runtime.shell.CommandProxy.execute(CommandProxy.java:50)[11:org.apache.karaf.shell.console:2.1.3]
>>> at
>>> org.apache.felix.gogo.runtime.shell.Closure.execute(Closure.java:229)[11:org.apache.karaf.shell.console:2.1.3]
>>> at
>>> org.apache.felix.gogo.runtime.shell.Closure.executeStatement(Closure.java:162)[11:org.apache.karaf.shell.console:2.1.3]
>>> at
>>> org.apache.felix.gogo.runtime.shell.Pipe.run(Pipe.java:101)[11:org.apache.karaf.shell.console:2.1.3]
>>> at
>>> org.apache.felix.gogo.runtime.shell.Closure.execute(Closure.java:79)[11:org.apache.karaf.shell.console:2.1.3]
>>> at
>>> org.apache.felix.gogo.runtime.shell.CommandSessionImpl.execute(CommandSessionImpl.java:71)[11:org.apache.karaf.shell.console:2.1.3]
>>> at
>>> org.apache.karaf.shell.console.jline.Console.run(Console.java:170)[11:org.apache.karaf.shell.console:2.1.3]
>>> at java.lang.Thread.run(Thread.java:662)[:1.6.0_23]
>>> Caused by: org.osgi.framework.BundleException: Unresolved constraint in
>>> bundle org.apache.servicemix.bundles.saaj-impl [97]: Unable to resolve 97.0:
>>> missing requirement [97.0] package;
>>> (package=com.sun.org.apache.xerces.internal.dom)
>>> at
>>> org.apache.felix.framework.Felix.resolveBundle(Felix.java:3409)[org.apache.felix.framework-3.0.2.jar:]
>>> at
>>> org.apache.felix.framework.Felix.startBundle(Felix.java:1709)[org.apache.felix.framework-3.0.2.jar:]
>>> at
>>> org.apache.felix.framework.BundleImpl.start(BundleImpl.java:905)[org.apache.felix.framework-3.0.2.jar:]
>>> at
>>> org.apache.felix.framework.BundleImpl.start(BundleImpl.java:892)[org.apache.felix.framework-3.0.2.jar:]
>>> at
>>> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeatures(FeaturesServiceImpl.java:323)[19:org.apache.karaf.features.core:2.1.3]
>>> ... 14 more
>>>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Thoughts about Karaf profiles / releases / growing number of
dependencies (Re: AW: AW: Problem when starting camel-cxf in karaf)
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
We are agree on that.
I think that the tiers applications (CXF, Camel, SMX, etc) using Karaf
should provide a karaf profile. A karaf profile could contain a features
descriptor and a "pre-configured" instance (including jre.properties and
others files).
Karaf default profile should contain only a minimal runtime container.
For instance, I'm not sure that the enterprise features is good think
talking about basically karaf itself.
I'm not pleased to introduce a large set of dependencies in Karaf:
releasing is harder and we have bottlenecks waiting to other projects.
Regarding this, I'm thinking about another "architecture":
- Karaf default distribution, including default profile, should stay as
"minimal" as possible without a large set
- We can create a APR (Application Profile Repository) to host
application related profiles (Camel, CXF, SMX, etc) or let the
applications host the profile on their repo.
Regards
JB
On 02/04/2011 12:07 AM, 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.
>
> 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.
>
> 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..).
>
> I certainly don't have a good answer yet, but I just want to make sure
> everyone is aware of the potential problem.
>
> 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.
>
> 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
> ....
>
> Sorry for the rant. There are a bunch of unrelated things here, ...
>
> On Wed, Feb 2, 2011 at 11:29, Jean-Baptiste Onofré<jb...@nanthrax.net> wrote:
>> 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 them in
>>> the karaf distribution.
>>>
>>> Best regards
>>>
>>> Christian
>>>
>>>
>>> -----Ursprüngliche Nachricht-----
>>> Von: Jean-Baptiste Onofré [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üngliche 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=com.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 | FelixStartLevel | jmx
>>>> | ? ? | 20 - org.apache.aries.jmx -
>>>> 0.2.0.incubating | Starting JMX OSGi agent
>>>> 09:46:09,781 | INFO | FelixStartLevel | jmx
>>>> | ? ? | 20 - org.apache.aries.jmx -
>>>> 0.2.0.incubating | Registering MBean with ObjectName
>>>> [osgi.compendium:service=cm,version=1.3] for service with service.id [10]
>>>> 09:46:09,796 | WARN | rint Extender: 3 | BlueprintContainerImpl
>>>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
>>>> 0.2.0.incubating | Bundle org.apache.karaf.features.command is waiting for
>>>> namespace handlers
>>>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
>>>> 09:46:09,796 | WARN | rint Extender: 2 | BlueprintContainerImpl
>>>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
>>>> 0.2.0.incubating | Bundle org.apache.karaf.shell.osgi is waiting for
>>>> namespace handlers
>>>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
>>>> 09:46:09,796 | WARN | JMX OSGi Agent | jmx
>>>> | ? ? | 20 - org.apache.aries.jmx -
>>>> 0.2.0.incubating | There are no MBean servers registred, can't register
>>>> MBeans
>>>> 09:46:09,890 | WARN | rint Extender: 2 | BlueprintContainerImpl
>>>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
>>>> 0.2.0.incubating | Bundle org.apache.karaf.shell.console is waiting for
>>>> namespace handlers
>>>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0))]
>>>> 09:46:09,968 | WARN | rint Extender: 2 | BlueprintContainerImpl
>>>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
>>>> 0.2.0.incubating | Bundle org.apache.karaf.shell.dev is waiting for
>>>> namespace handlers
>>>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
>>>> 09:46:10,218 | WARN | rint Extender: 3 | BlueprintContainerImpl
>>>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
>>>> 0.2.0.incubating | Bundle org.apache.karaf.shell.ssh is waiting for
>>>> namespace handlers
>>>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
>>>> 09:46:10,234 | WARN | rint Extender: 3 | BlueprintContainerImpl
>>>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
>>>> 0.2.0.incubating | Bundle org.apache.karaf.admin.command is waiting for
>>>> namespace handlers
>>>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
>>>> 09:46:10,250 | WARN | rint Extender: 3 | BlueprintContainerImpl
>>>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
>>>> 0.2.0.incubating | Bundle org.apache.karaf.shell.commands is waiting for
>>>> namespace handlers
>>>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
>>>> 09:46:10,375 | WARN | rint Extender: 2 | BlueprintContainerImpl
>>>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
>>>> 0.2.0.incubating | Bundle org.apache.karaf.shell.packages is waiting for
>>>> namespace handlers
>>>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
>>>> 09:46:11,609 | INFO | Thread-5 | FeaturesServiceImpl
>>>> | res.internal.FeaturesServiceImpl 293 | 19 -
>>>> org.apache.karaf.features.core - 2.1.3 | Bundles to refresh:
>>>> 09:46:11,640 | INFO | rint Extender: 3 | SecurityUtils
>>>> | e.sshd.common.util.SecurityUtils 80 | 25 - sshd-core - 0.4.0 |
>>>> BouncyCastle not registered, using the default JCE provider
>>>> 09:46:11,968 | INFO | JMX OSGi Agent | jmx
>>>> | ? ? | 20 - org.apache.aries.jmx -
>>>> 0.2.0.incubating | Registering org.osgi.jmx.framework.BundleStateMBean to
>>>> MBeanServer com.sun.jmx.mbeanserver.JmxMBeanServer@6e3d60 with name
>>>> osgi.core:type=bundleState,version=1.5
>>>> 09:46:12,000 | INFO | JMX OSGi Agent | jmx
>>>> | ? ? | 20 - org.apache.aries.jmx -
>>>> 0.2.0.incubating | Registering org.osgi.jmx.framework.ServiceStateMBean to
>>>> MBeanServer com.sun.jmx.mbeanserver.JmxMBeanServer@6e3d60 with name
>>>> osgi.core:type=serviceState,version=1.5
>>>> 09:46:12,000 | INFO | JMX OSGi Agent | jmx
>>>> | ? ? | 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=framework,version=1.5
>>>> 09:46:12,031 | INFO | JMX OSGi Agent | jmx
>>>> | ? ? | 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=cm,version=1.3
>>>> 09:46:12,031 | INFO | JMX OSGi Agent | jmx
>>>> | ? ? | 20 - org.apache.aries.jmx -
>>>> 0.2.0.incubating | Registering org.osgi.jmx.framework.PackageStateMBean to
>>>> MBeanServer com.sun.jmx.mbeanserver.JmxMBeanServer@6e3d60 with name
>>>> osgi.core:type=packageState,version=1.5
>>>> 09:48:08,234 | INFO | l Console Thread | FeaturesServiceImpl
>>>> | res.internal.FeaturesServiceImpl 293 | 19 -
>>>> org.apache.karaf.features.core - 2.1.3 | Bundles to refresh:
>>>> 09:48:08,656 | INFO | l Console Thread | ContextLoaderListener
>>>> | .activator.ContextLoaderListener 356 | 44 -
>>>> org.springframework.osgi.extender - 1.2.0 | Starting
>>>> [org.springframework.osgi.extender] bundle v.[1.2.0]
>>>> 09:48:08,781 | INFO | l Console Thread | ExtenderConfiguration
>>>> | al.support.ExtenderConfiguration 150 | 44 -
>>>> org.springframework.osgi.extender - 1.2.0 | No custom extender configuration
>>>> detected; using defaults...
>>>> 09:48:08,781 | INFO | l Console Thread | TimerTaskExecutor
>>>> | heduling.timer.TimerTaskExecutor 106 | 38 - org.springframework.context
>>>> - 3.0.5.RELEASE | Initializing Timer
>>>> 09:48:09,281 | INFO | l Console Thread | Activator
>>>> | apache.camel.impl.osgi.Activator 83 | 51 - org.apache.camel.camel-core
>>>> - 2.6.0 | Camel activator starting
>>>> 09:48:09,312 | INFO | l Console Thread | Activator
>>>> | apache.camel.impl.osgi.Activator 86 | 51 - org.apache.camel.camel-core
>>>> - 2.6.0 | Camel activator started
>>>> 09:48:10,968 | INFO | l Console Thread | Activator
>>>> | apache.camel.impl.osgi.Activator 90 | 51 - org.apache.camel.camel-core
>>>> - 2.6.0 | Camel activator stopping
>>>> 09:48:10,968 | INFO | l Console Thread | Activator
>>>> | apache.camel.impl.osgi.Activator 92 | 51 - org.apache.camel.camel-core
>>>> - 2.6.0 | Camel activator stopped
>>>> 09:48:11,984 | INFO | l Console Thread | ContextLoaderListener
>>>> | .activator.ContextLoaderListener 449 | 44 -
>>>> org.springframework.osgi.extender - 1.2.0 | Stopping
>>>> [org.springframework.osgi.extender] bundle v.[1.2.0]
>>>> 09:48:11,984 | INFO | l Console Thread | TimerTaskExecutor
>>>> | heduling.timer.TimerTaskExecutor 179 | 38 - org.springframework.context
>>>> - 3.0.5.RELEASE | Cancelling Timer
>>>> 09:48:12,281 | INFO | l Console Thread | Console
>>>> | araf.shell.console.jline.Console 188 | 11 -
>>>> org.apache.karaf.shell.console - 2.1.3 | Exception caught while executing
>>>> 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=com.sun.org.apache.xerces.internal.dom)
>>>> at
>>>> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeatures(FeaturesServiceImpl.java:326)[19:org.apache.karaf.features.core:2.1.3]
>>>> at
>>>> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(FeaturesServiceImpl.java:254)[19:org.apache.karaf.features.core:2.1.3]
>>>> at
>>>> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(FeaturesServiceImpl.java:250)[19:org.apache.karaf.features.core:2.1.3]
>>>> at
>>>> org.apache.karaf.features.command.InstallFeatureCommand.doExecute(InstallFeatureCommand.java:51)[9:org.apache.karaf.features.command:2.1.3]
>>>> at
>>>> org.apache.karaf.features.command.FeaturesCommandSupport.doExecute(FeaturesCommandSupport.java:39)[9:org.apache.karaf.features.command:2.1.3]
>>>> at
>>>> org.apache.karaf.shell.console.OsgiCommandSupport.execute(OsgiCommandSupport.java:38)[11:org.apache.karaf.shell.console:2.1.3]
>>>> at
>>>> org.apache.felix.gogo.commands.basic.AbstractCommand.execute(AbstractCommand.java:35)[11:org.apache.karaf.shell.console:2.1.3]
>>>> at
>>>> org.apache.felix.gogo.runtime.shell.CommandProxy.execute(CommandProxy.java:50)[11:org.apache.karaf.shell.console:2.1.3]
>>>> at
>>>> org.apache.felix.gogo.runtime.shell.Closure.execute(Closure.java:229)[11:org.apache.karaf.shell.console:2.1.3]
>>>> at
>>>> org.apache.felix.gogo.runtime.shell.Closure.executeStatement(Closure.java:162)[11:org.apache.karaf.shell.console:2.1.3]
>>>> at
>>>> org.apache.felix.gogo.runtime.shell.Pipe.run(Pipe.java:101)[11:org.apache.karaf.shell.console:2.1.3]
>>>> at
>>>> org.apache.felix.gogo.runtime.shell.Closure.execute(Closure.java:79)[11:org.apache.karaf.shell.console:2.1.3]
>>>> at
>>>> org.apache.felix.gogo.runtime.shell.CommandSessionImpl.execute(CommandSessionImpl.java:71)[11:org.apache.karaf.shell.console:2.1.3]
>>>> at
>>>> org.apache.karaf.shell.console.jline.Console.run(Console.java:170)[11:org.apache.karaf.shell.console:2.1.3]
>>>> at java.lang.Thread.run(Thread.java:662)[:1.6.0_23]
>>>> Caused by: org.osgi.framework.BundleException: Unresolved constraint in
>>>> bundle org.apache.servicemix.bundles.saaj-impl [97]: Unable to resolve 97.0:
>>>> missing requirement [97.0] package;
>>>> (package=com.sun.org.apache.xerces.internal.dom)
>>>> at
>>>> org.apache.felix.framework.Felix.resolveBundle(Felix.java:3409)[org.apache.felix.framework-3.0.2.jar:]
>>>> at
>>>> org.apache.felix.framework.Felix.startBundle(Felix.java:1709)[org.apache.felix.framework-3.0.2.jar:]
>>>> at
>>>> org.apache.felix.framework.BundleImpl.start(BundleImpl.java:905)[org.apache.felix.framework-3.0.2.jar:]
>>>> at
>>>> org.apache.felix.framework.BundleImpl.start(BundleImpl.java:892)[org.apache.felix.framework-3.0.2.jar:]
>>>> at
>>>> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeatures(FeaturesServiceImpl.java:323)[19:org.apache.karaf.features.core:2.1.3]
>>>> ... 14 more
>>>>
>>
>
>
>
Re: Thoughts about Karaf profiles / releases / growing number of dependencies (Re: AW: AW: Problem when starting camel-cxf in karaf)
Posted by David Jencks <da...@yahoo.com>.
I don't know how to deal with needing to change stuff in what I've put in the "framework" kar. Maybe we can do something fancier with branding to overwrite or merge more standard files. I don't think system properties solutions are reasonable.
I've been assuming that our goal is to make it really easy for everyone to make features, kars, and assemblies for their project so that in a few trivial maven projects that take 15 minutes to set up they can construct a feature or kar to install their project on an existing karaf server and also a customized stand alone karaf server with their project pre installed. The worst-case alternative is all of geronimo getting pushed back into karaf which I'm sure no one wants :-D
For stuff we can't manage to push back to the originating project that we still want to support perhaps we can have less monolithic releases like felix has?
thanks
david jencks
On Feb 3, 2011, at 3:07 PM, 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.
>
> 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.
>
> 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..).
>
> I certainly don't have a good answer yet, but I just want to make sure
> everyone is aware of the potential problem.
>
> 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.
>
> 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
> ....
>
> Sorry for the rant. There are a bunch of unrelated things here, ...
>
> On Wed, Feb 2, 2011 at 11:29, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>> 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 them in
>>> the karaf distribution.
>>>
>>> Best regards
>>>
>>> Christian
>>>
>>>
>>> -----Ursprüngliche Nachricht-----
>>> Von: Jean-Baptiste Onofré [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üngliche 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=com.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 | FelixStartLevel | jmx
>>>> | ? ? | 20 - org.apache.aries.jmx -
>>>> 0.2.0.incubating | Starting JMX OSGi agent
>>>> 09:46:09,781 | INFO | FelixStartLevel | jmx
>>>> | ? ? | 20 - org.apache.aries.jmx -
>>>> 0.2.0.incubating | Registering MBean with ObjectName
>>>> [osgi.compendium:service=cm,version=1.3] for service with service.id [10]
>>>> 09:46:09,796 | WARN | rint Extender: 3 | BlueprintContainerImpl
>>>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
>>>> 0.2.0.incubating | Bundle org.apache.karaf.features.command is waiting for
>>>> namespace handlers
>>>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
>>>> 09:46:09,796 | WARN | rint Extender: 2 | BlueprintContainerImpl
>>>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
>>>> 0.2.0.incubating | Bundle org.apache.karaf.shell.osgi is waiting for
>>>> namespace handlers
>>>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
>>>> 09:46:09,796 | WARN | JMX OSGi Agent | jmx
>>>> | ? ? | 20 - org.apache.aries.jmx -
>>>> 0.2.0.incubating | There are no MBean servers registred, can't register
>>>> MBeans
>>>> 09:46:09,890 | WARN | rint Extender: 2 | BlueprintContainerImpl
>>>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
>>>> 0.2.0.incubating | Bundle org.apache.karaf.shell.console is waiting for
>>>> namespace handlers
>>>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0))]
>>>> 09:46:09,968 | WARN | rint Extender: 2 | BlueprintContainerImpl
>>>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
>>>> 0.2.0.incubating | Bundle org.apache.karaf.shell.dev is waiting for
>>>> namespace handlers
>>>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
>>>> 09:46:10,218 | WARN | rint Extender: 3 | BlueprintContainerImpl
>>>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
>>>> 0.2.0.incubating | Bundle org.apache.karaf.shell.ssh is waiting for
>>>> namespace handlers
>>>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
>>>> 09:46:10,234 | WARN | rint Extender: 3 | BlueprintContainerImpl
>>>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
>>>> 0.2.0.incubating | Bundle org.apache.karaf.admin.command is waiting for
>>>> namespace handlers
>>>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
>>>> 09:46:10,250 | WARN | rint Extender: 3 | BlueprintContainerImpl
>>>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
>>>> 0.2.0.incubating | Bundle org.apache.karaf.shell.commands is waiting for
>>>> namespace handlers
>>>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
>>>> 09:46:10,375 | WARN | rint Extender: 2 | BlueprintContainerImpl
>>>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
>>>> 0.2.0.incubating | Bundle org.apache.karaf.shell.packages is waiting for
>>>> namespace handlers
>>>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
>>>> 09:46:11,609 | INFO | Thread-5 | FeaturesServiceImpl
>>>> | res.internal.FeaturesServiceImpl 293 | 19 -
>>>> org.apache.karaf.features.core - 2.1.3 | Bundles to refresh:
>>>> 09:46:11,640 | INFO | rint Extender: 3 | SecurityUtils
>>>> | e.sshd.common.util.SecurityUtils 80 | 25 - sshd-core - 0.4.0 |
>>>> BouncyCastle not registered, using the default JCE provider
>>>> 09:46:11,968 | INFO | JMX OSGi Agent | jmx
>>>> | ? ? | 20 - org.apache.aries.jmx -
>>>> 0.2.0.incubating | Registering org.osgi.jmx.framework.BundleStateMBean to
>>>> MBeanServer com.sun.jmx.mbeanserver.JmxMBeanServer@6e3d60 with name
>>>> osgi.core:type=bundleState,version=1.5
>>>> 09:46:12,000 | INFO | JMX OSGi Agent | jmx
>>>> | ? ? | 20 - org.apache.aries.jmx -
>>>> 0.2.0.incubating | Registering org.osgi.jmx.framework.ServiceStateMBean to
>>>> MBeanServer com.sun.jmx.mbeanserver.JmxMBeanServer@6e3d60 with name
>>>> osgi.core:type=serviceState,version=1.5
>>>> 09:46:12,000 | INFO | JMX OSGi Agent | jmx
>>>> | ? ? | 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=framework,version=1.5
>>>> 09:46:12,031 | INFO | JMX OSGi Agent | jmx
>>>> | ? ? | 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=cm,version=1.3
>>>> 09:46:12,031 | INFO | JMX OSGi Agent | jmx
>>>> | ? ? | 20 - org.apache.aries.jmx -
>>>> 0.2.0.incubating | Registering org.osgi.jmx.framework.PackageStateMBean to
>>>> MBeanServer com.sun.jmx.mbeanserver.JmxMBeanServer@6e3d60 with name
>>>> osgi.core:type=packageState,version=1.5
>>>> 09:48:08,234 | INFO | l Console Thread | FeaturesServiceImpl
>>>> | res.internal.FeaturesServiceImpl 293 | 19 -
>>>> org.apache.karaf.features.core - 2.1.3 | Bundles to refresh:
>>>> 09:48:08,656 | INFO | l Console Thread | ContextLoaderListener
>>>> | .activator.ContextLoaderListener 356 | 44 -
>>>> org.springframework.osgi.extender - 1.2.0 | Starting
>>>> [org.springframework.osgi.extender] bundle v.[1.2.0]
>>>> 09:48:08,781 | INFO | l Console Thread | ExtenderConfiguration
>>>> | al.support.ExtenderConfiguration 150 | 44 -
>>>> org.springframework.osgi.extender - 1.2.0 | No custom extender configuration
>>>> detected; using defaults...
>>>> 09:48:08,781 | INFO | l Console Thread | TimerTaskExecutor
>>>> | heduling.timer.TimerTaskExecutor 106 | 38 - org.springframework.context
>>>> - 3.0.5.RELEASE | Initializing Timer
>>>> 09:48:09,281 | INFO | l Console Thread | Activator
>>>> | apache.camel.impl.osgi.Activator 83 | 51 - org.apache.camel.camel-core
>>>> - 2.6.0 | Camel activator starting
>>>> 09:48:09,312 | INFO | l Console Thread | Activator
>>>> | apache.camel.impl.osgi.Activator 86 | 51 - org.apache.camel.camel-core
>>>> - 2.6.0 | Camel activator started
>>>> 09:48:10,968 | INFO | l Console Thread | Activator
>>>> | apache.camel.impl.osgi.Activator 90 | 51 - org.apache.camel.camel-core
>>>> - 2.6.0 | Camel activator stopping
>>>> 09:48:10,968 | INFO | l Console Thread | Activator
>>>> | apache.camel.impl.osgi.Activator 92 | 51 - org.apache.camel.camel-core
>>>> - 2.6.0 | Camel activator stopped
>>>> 09:48:11,984 | INFO | l Console Thread | ContextLoaderListener
>>>> | .activator.ContextLoaderListener 449 | 44 -
>>>> org.springframework.osgi.extender - 1.2.0 | Stopping
>>>> [org.springframework.osgi.extender] bundle v.[1.2.0]
>>>> 09:48:11,984 | INFO | l Console Thread | TimerTaskExecutor
>>>> | heduling.timer.TimerTaskExecutor 179 | 38 - org.springframework.context
>>>> - 3.0.5.RELEASE | Cancelling Timer
>>>> 09:48:12,281 | INFO | l Console Thread | Console
>>>> | araf.shell.console.jline.Console 188 | 11 -
>>>> org.apache.karaf.shell.console - 2.1.3 | Exception caught while executing
>>>> 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=com.sun.org.apache.xerces.internal.dom)
>>>> at
>>>> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeatures(FeaturesServiceImpl.java:326)[19:org.apache.karaf.features.core:2.1.3]
>>>> at
>>>> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(FeaturesServiceImpl.java:254)[19:org.apache.karaf.features.core:2.1.3]
>>>> at
>>>> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(FeaturesServiceImpl.java:250)[19:org.apache.karaf.features.core:2.1.3]
>>>> at
>>>> org.apache.karaf.features.command.InstallFeatureCommand.doExecute(InstallFeatureCommand.java:51)[9:org.apache.karaf.features.command:2.1.3]
>>>> at
>>>> org.apache.karaf.features.command.FeaturesCommandSupport.doExecute(FeaturesCommandSupport.java:39)[9:org.apache.karaf.features.command:2.1.3]
>>>> at
>>>> org.apache.karaf.shell.console.OsgiCommandSupport.execute(OsgiCommandSupport.java:38)[11:org.apache.karaf.shell.console:2.1.3]
>>>> at
>>>> org.apache.felix.gogo.commands.basic.AbstractCommand.execute(AbstractCommand.java:35)[11:org.apache.karaf.shell.console:2.1.3]
>>>> at
>>>> org.apache.felix.gogo.runtime.shell.CommandProxy.execute(CommandProxy.java:50)[11:org.apache.karaf.shell.console:2.1.3]
>>>> at
>>>> org.apache.felix.gogo.runtime.shell.Closure.execute(Closure.java:229)[11:org.apache.karaf.shell.console:2.1.3]
>>>> at
>>>> org.apache.felix.gogo.runtime.shell.Closure.executeStatement(Closure.java:162)[11:org.apache.karaf.shell.console:2.1.3]
>>>> at
>>>> org.apache.felix.gogo.runtime.shell.Pipe.run(Pipe.java:101)[11:org.apache.karaf.shell.console:2.1.3]
>>>> at
>>>> org.apache.felix.gogo.runtime.shell.Closure.execute(Closure.java:79)[11:org.apache.karaf.shell.console:2.1.3]
>>>> at
>>>> org.apache.felix.gogo.runtime.shell.CommandSessionImpl.execute(CommandSessionImpl.java:71)[11:org.apache.karaf.shell.console:2.1.3]
>>>> at
>>>> org.apache.karaf.shell.console.jline.Console.run(Console.java:170)[11:org.apache.karaf.shell.console:2.1.3]
>>>> at java.lang.Thread.run(Thread.java:662)[:1.6.0_23]
>>>> Caused by: org.osgi.framework.BundleException: Unresolved constraint in
>>>> bundle org.apache.servicemix.bundles.saaj-impl [97]: Unable to resolve 97.0:
>>>> missing requirement [97.0] package;
>>>> (package=com.sun.org.apache.xerces.internal.dom)
>>>> at
>>>> org.apache.felix.framework.Felix.resolveBundle(Felix.java:3409)[org.apache.felix.framework-3.0.2.jar:]
>>>> at
>>>> org.apache.felix.framework.Felix.startBundle(Felix.java:1709)[org.apache.felix.framework-3.0.2.jar:]
>>>> at
>>>> org.apache.felix.framework.BundleImpl.start(BundleImpl.java:905)[org.apache.felix.framework-3.0.2.jar:]
>>>> at
>>>> org.apache.felix.framework.BundleImpl.start(BundleImpl.java:892)[org.apache.felix.framework-3.0.2.jar:]
>>>> at
>>>> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeatures(FeaturesServiceImpl.java:323)[19:org.apache.karaf.features.core:2.1.3]
>>>> ... 14 more
>>>>
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
Re: Thoughts about Karaf profiles / releases / growing number of
dependencies (Re: AW: AW: Problem when starting camel-cxf in karaf)
Posted by mikevan <mv...@comcast.net>.
Oooo threadjack!
To get things back on point, I make the following suggestions. Don't take
the tone of the suggestions to strongly, this is just my opinion.
I agree with Guillaume that we can't have too many dependencies on other
products. If this were an J2EE container, we would include specific items
implementing the J2EE functionality as defined by the spec, and a few "nice
to haves". Then, anyone who wanted to add functionalilty would need to do so
by themselves. If we look at Karaf as a container that implements all the
bells and whistles of the current OSGi specification, we will have a nice
line of demarcation.
So, when deciding on a new piece of functionality:
1) License? (ASL or not a candidate)
2) does it implement something defined in the OSGi spec (services,
provisioning, etc),
3) Is its intent to be specific to Karaf (Cellar yes, Aries no), and
3) Are there other products that can implement that functionality using
Karaf already?
If a piece of functionality (or another product) gets a no (or a weak maybe)
in one or more of the above categories, they would be a great candidate for
use with Karaf, but not as part of the Karaf distribution. If, like Cellar,
they are specific to Karaf and add functionality we would like users to
have, then they would be a great candidate to be a sub-project. Any
sub-project or other product that wants to work with Karaf would be
responsible for making sure it runs in vanilla Karaf (creating a
features.xml file, deploying, working, etc) and doing regular releases
(defined as a full product distribution deliverables complete with their own
.zip or .tar and a features.xml file).
The last caveat I'd like to add is that if a product is optional, or
external to vanilla Karaf, it should have its own distribution. The biggest
question this creates is: what to we do with things that are technically
optional, but so tightly itertwined with Karaf that they won't work outside
of Karaf? For example, how do we treat the webconsole? Well, either it is
part of the vanilla Karaf distribution, or it is not. If it is not, we
should create a seperate deliverable for it. That way, there's no confusion
about how to get it (especially for environments that are not connected to
the big-bad internet.)
gsilverman wrote:
>
> You camel/karaf officiondos can yap all you want to each other. All I want
> to do is run camel-cxf in karaf, and I can't. I even tried camel-cxf
> 2.8-SNAPSHOT with karaf 2.2.1. The instructions on the Apache Camel:CXF
> Example OSGi page, if anyone can actually follow them, don't work (is
> there a cxf feature to install?).
>
> I even tried replacing the etc/jre.properties in Karaf with the one in
> ServiceMix 4.3, as someone suggested, and that didn't work.
>
> If there's a secret to get this to run, I and I'm sure a lot of others
> would like to hear about it.
>
-----
Mike Van (aka karafman)
Karaf Team (Contributor)
--
View this message in context: http://karaf.922171.n3.nabble.com/Thoughts-about-Karaf-profiles-releases-growing-number-of-dependencies-Re-AW-AW-Problem-when-starting-tp2419227p2954108.html
Sent from the Karaf - Dev mailing list archive at Nabble.com.
Re: Thoughts about Karaf profiles / releases / growing number of
dependencies (Re: AW: AW: Problem when starting camel-cxf in karaf)
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
OK guys I got it.
Here's the workaround:
- I took Karaf 2.2.1 from scratch and uncompress
- I changed the etc/jre.properties, in the jre-1.6 section, by:
* commenting the following lines:
# javax.activation, \
[...]
# javax.annotation, \
# javax.annotation.processing, \
[...]
# javax.jws, \
# javax.jws.soap, \
[...]
#javax.xml.bind, \
#javax.xml.bind.annotation, \
#javax.xml.bind.annotation.adapters, \
#javax.xml.bind.attachment, \
#javax.xml.bind.helpers, \
#javax.xml.bind.util, \
[...]
#javax.xml.soap, \
#javax.xml.stream, \
#javax.xml.stream.events, \
#javax.xml.stream.util, \
[...]
#javax.xml.ws, \
#javax.xml.ws.handler, \
#javax.xml.ws.handler.soap, \
#javax.xml.ws.http, \
#javax.xml.ws.soap, \
#javax.xml.ws.spi, \
#javax.xml.ws.wsaddressing, \
[...]
* adding the following lines at the end:
com.sun.org.apache.xerces.internal.dom, \
com.sun.org.apache.xerces.internal.jaxp
- After the added the camel features descriptor URL
- And installed the camel-cxf feature without problem
Regards
JB
On 05/17/2011 12:53 PM, akuhtz wrote:
> Hi JB,
>
> I've the same problem:
> * Start with fresh karaf-2.2.1 (extracted from assembly.zip),
> * add the camel features url in the console: features:addurl
> mvn:org.apache.camel.karaf/apache-camel/2.8-SNAPSHOT/xml/features
> * try to install camel-cxf feature: features:install camel-cxf
>
> After a while the following is printed in the console:
> Error executing command: Could not start bundle
> mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.saaj-imp
> l/1.3.2_1 in feature(s) camel-cxf-2.8-SNAPSHOT: Unresolved constraint in
> bundle org.apache.servicemix.bundles.saaj-impl
> [105]: Unable to resolve 105.0: missing requirement [105.0] package;
> (package=com.sun.org.apache.xerces.internal.dom)
>
> My env:
> java version "1.6.0_23"
> Java(TM) SE Runtime Environment (build 1.6.0_23-b05)
> Java HotSpot(TM) Client VM (build 19.0-b09, mixed mode, sharing)
>
> Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
> Java version: 1.6.0_23
> Java home: C:\Siemens\Java\jdk1.6.0_23\jre
> Default locale: de_CH, platform encoding: Cp1252
> OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
>
> Regards
> Andi
>
>
> --
> View this message in context: http://karaf.922171.n3.nabble.com/Thoughts-about-Karaf-profiles-releases-growing-number-of-dependencies-Re-AW-AW-Problem-when-starting-tp2419227p2951998.html
> Sent from the Karaf - Dev mailing list archive at Nabble.com.
Re: Thoughts about Karaf profiles / releases / growing number of
dependencies (Re: AW: AW: Problem when starting camel-cxf in karaf)
Posted by akuhtz <an...@siemens.com>.
Hi JB,
I've the same problem:
* Start with fresh karaf-2.2.1 (extracted from assembly.zip),
* add the camel features url in the console: features:addurl
mvn:org.apache.camel.karaf/apache-camel/2.8-SNAPSHOT/xml/features
* try to install camel-cxf feature: features:install camel-cxf
After a while the following is printed in the console:
Error executing command: Could not start bundle
mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.saaj-imp
l/1.3.2_1 in feature(s) camel-cxf-2.8-SNAPSHOT: Unresolved constraint in
bundle org.apache.servicemix.bundles.saaj-impl
[105]: Unable to resolve 105.0: missing requirement [105.0] package;
(package=com.sun.org.apache.xerces.internal.dom)
My env:
java version "1.6.0_23"
Java(TM) SE Runtime Environment (build 1.6.0_23-b05)
Java HotSpot(TM) Client VM (build 19.0-b09, mixed mode, sharing)
Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
Java version: 1.6.0_23
Java home: C:\Siemens\Java\jdk1.6.0_23\jre
Default locale: de_CH, platform encoding: Cp1252
OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
Regards
Andi
--
View this message in context: http://karaf.922171.n3.nabble.com/Thoughts-about-Karaf-profiles-releases-growing-number-of-dependencies-Re-AW-AW-Problem-when-starting-tp2419227p2951998.html
Sent from the Karaf - Dev mailing list archive at Nabble.com.
Re: Thoughts about Karaf profiles / releases / growing number of
dependencies (Re: AW: AW: Problem when starting camel-cxf in karaf)
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi,
could you remind us the issue that you have ?
Regards
JB
On 05/17/2011 02:36 AM, gsilverman wrote:
> You camel/karaf officiondos can yap all you want to each other. All I want to
> do is run camel-cxf in karaf, and I can't. I even tried camel-cxf
> 2.8-SNAPSHOT with karaf 2.2.1. The instructions on the Apache Camel:CXF
> Example OSGi page, if anyone can actually follow them, don't work (is there
> a cxf feature to install?).
>
> I even tried replacing the etc/jre.properties in Karaf with the one in
> ServiceMix 4.3, as someone suggested, and that didn't work.
>
> If there's a secret to get this to run, I and I'm sure a lot of others would
> like to hear about it.
>
> --
> View this message in context: http://karaf.922171.n3.nabble.com/Thoughts-about-Karaf-profiles-releases-growing-number-of-dependencies-Re-AW-AW-Problem-when-starting-tp2419227p2950627.html
> Sent from the Karaf - Dev mailing list archive at Nabble.com.
Re: Thoughts about Karaf profiles / releases / growing number of
dependencies (Re: AW: AW: Problem when starting camel-cxf in karaf)
Posted by gsilverman <gs...@dispensingsolutionsinc.com>.
You camel/karaf officiondos can yap all you want to each other. All I want to
do is run camel-cxf in karaf, and I can't. I even tried camel-cxf
2.8-SNAPSHOT with karaf 2.2.1. The instructions on the Apache Camel:CXF
Example OSGi page, if anyone can actually follow them, don't work (is there
a cxf feature to install?).
I even tried replacing the etc/jre.properties in Karaf with the one in
ServiceMix 4.3, as someone suggested, and that didn't work.
If there's a secret to get this to run, I and I'm sure a lot of others would
like to hear about it.
--
View this message in context: http://karaf.922171.n3.nabble.com/Thoughts-about-Karaf-profiles-releases-growing-number-of-dependencies-Re-AW-AW-Problem-when-starting-tp2419227p2950627.html
Sent from the Karaf - Dev mailing list archive at Nabble.com.
Re: Thoughts about Karaf profiles / releases / growing number of
dependencies (Re: AW: AW: Problem when starting camel-cxf in karaf)
Posted by Guillaume Nodet <gn...@gmail.com>.
Another way to solve the dependencies problem could also be to forbid
any snapshot dependencies.
That would allow us to do releases much more easily at the cost of
delaying bug fixes into trunk until the dependencies are actually
released.
On Fri, Feb 4, 2011 at 00:07, Guillaume Nodet <gn...@gmail.com> 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.
>
> 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.
>
> 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..).
>
> I certainly don't have a good answer yet, but I just want to make sure
> everyone is aware of the potential problem.
>
> 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.
>
> 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
> ....
>
> Sorry for the rant. There are a bunch of unrelated things here, ...
>
> On Wed, Feb 2, 2011 at 11:29, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>> 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 them in
>>> the karaf distribution.
>>>
>>> Best regards
>>>
>>> Christian
>>>
>>>
>>> -----Ursprüngliche Nachricht-----
>>> Von: Jean-Baptiste Onofré [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üngliche 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=com.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 | FelixStartLevel | jmx
>>>> | ? ? | 20 - org.apache.aries.jmx -
>>>> 0.2.0.incubating | Starting JMX OSGi agent
>>>> 09:46:09,781 | INFO | FelixStartLevel | jmx
>>>> | ? ? | 20 - org.apache.aries.jmx -
>>>> 0.2.0.incubating | Registering MBean with ObjectName
>>>> [osgi.compendium:service=cm,version=1.3] for service with service.id [10]
>>>> 09:46:09,796 | WARN | rint Extender: 3 | BlueprintContainerImpl
>>>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
>>>> 0.2.0.incubating | Bundle org.apache.karaf.features.command is waiting for
>>>> namespace handlers
>>>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
>>>> 09:46:09,796 | WARN | rint Extender: 2 | BlueprintContainerImpl
>>>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
>>>> 0.2.0.incubating | Bundle org.apache.karaf.shell.osgi is waiting for
>>>> namespace handlers
>>>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
>>>> 09:46:09,796 | WARN | JMX OSGi Agent | jmx
>>>> | ? ? | 20 - org.apache.aries.jmx -
>>>> 0.2.0.incubating | There are no MBean servers registred, can't register
>>>> MBeans
>>>> 09:46:09,890 | WARN | rint Extender: 2 | BlueprintContainerImpl
>>>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
>>>> 0.2.0.incubating | Bundle org.apache.karaf.shell.console is waiting for
>>>> namespace handlers
>>>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0))]
>>>> 09:46:09,968 | WARN | rint Extender: 2 | BlueprintContainerImpl
>>>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
>>>> 0.2.0.incubating | Bundle org.apache.karaf.shell.dev is waiting for
>>>> namespace handlers
>>>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
>>>> 09:46:10,218 | WARN | rint Extender: 3 | BlueprintContainerImpl
>>>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
>>>> 0.2.0.incubating | Bundle org.apache.karaf.shell.ssh is waiting for
>>>> namespace handlers
>>>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
>>>> 09:46:10,234 | WARN | rint Extender: 3 | BlueprintContainerImpl
>>>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
>>>> 0.2.0.incubating | Bundle org.apache.karaf.admin.command is waiting for
>>>> namespace handlers
>>>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
>>>> 09:46:10,250 | WARN | rint Extender: 3 | BlueprintContainerImpl
>>>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
>>>> 0.2.0.incubating | Bundle org.apache.karaf.shell.commands is waiting for
>>>> namespace handlers
>>>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
>>>> 09:46:10,375 | WARN | rint Extender: 2 | BlueprintContainerImpl
>>>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
>>>> 0.2.0.incubating | Bundle org.apache.karaf.shell.packages is waiting for
>>>> namespace handlers
>>>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
>>>> 09:46:11,609 | INFO | Thread-5 | FeaturesServiceImpl
>>>> | res.internal.FeaturesServiceImpl 293 | 19 -
>>>> org.apache.karaf.features.core - 2.1.3 | Bundles to refresh:
>>>> 09:46:11,640 | INFO | rint Extender: 3 | SecurityUtils
>>>> | e.sshd.common.util.SecurityUtils 80 | 25 - sshd-core - 0.4.0 |
>>>> BouncyCastle not registered, using the default JCE provider
>>>> 09:46:11,968 | INFO | JMX OSGi Agent | jmx
>>>> | ? ? | 20 - org.apache.aries.jmx -
>>>> 0.2.0.incubating | Registering org.osgi.jmx.framework.BundleStateMBean to
>>>> MBeanServer com.sun.jmx.mbeanserver.JmxMBeanServer@6e3d60 with name
>>>> osgi.core:type=bundleState,version=1.5
>>>> 09:46:12,000 | INFO | JMX OSGi Agent | jmx
>>>> | ? ? | 20 - org.apache.aries.jmx -
>>>> 0.2.0.incubating | Registering org.osgi.jmx.framework.ServiceStateMBean to
>>>> MBeanServer com.sun.jmx.mbeanserver.JmxMBeanServer@6e3d60 with name
>>>> osgi.core:type=serviceState,version=1.5
>>>> 09:46:12,000 | INFO | JMX OSGi Agent | jmx
>>>> | ? ? | 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=framework,version=1.5
>>>> 09:46:12,031 | INFO | JMX OSGi Agent | jmx
>>>> | ? ? | 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=cm,version=1.3
>>>> 09:46:12,031 | INFO | JMX OSGi Agent | jmx
>>>> | ? ? | 20 - org.apache.aries.jmx -
>>>> 0.2.0.incubating | Registering org.osgi.jmx.framework.PackageStateMBean to
>>>> MBeanServer com.sun.jmx.mbeanserver.JmxMBeanServer@6e3d60 with name
>>>> osgi.core:type=packageState,version=1.5
>>>> 09:48:08,234 | INFO | l Console Thread | FeaturesServiceImpl
>>>> | res.internal.FeaturesServiceImpl 293 | 19 -
>>>> org.apache.karaf.features.core - 2.1.3 | Bundles to refresh:
>>>> 09:48:08,656 | INFO | l Console Thread | ContextLoaderListener
>>>> | .activator.ContextLoaderListener 356 | 44 -
>>>> org.springframework.osgi.extender - 1.2.0 | Starting
>>>> [org.springframework.osgi.extender] bundle v.[1.2.0]
>>>> 09:48:08,781 | INFO | l Console Thread | ExtenderConfiguration
>>>> | al.support.ExtenderConfiguration 150 | 44 -
>>>> org.springframework.osgi.extender - 1.2.0 | No custom extender configuration
>>>> detected; using defaults...
>>>> 09:48:08,781 | INFO | l Console Thread | TimerTaskExecutor
>>>> | heduling.timer.TimerTaskExecutor 106 | 38 - org.springframework.context
>>>> - 3.0.5.RELEASE | Initializing Timer
>>>> 09:48:09,281 | INFO | l Console Thread | Activator
>>>> | apache.camel.impl.osgi.Activator 83 | 51 - org.apache.camel.camel-core
>>>> - 2.6.0 | Camel activator starting
>>>> 09:48:09,312 | INFO | l Console Thread | Activator
>>>> | apache.camel.impl.osgi.Activator 86 | 51 - org.apache.camel.camel-core
>>>> - 2.6.0 | Camel activator started
>>>> 09:48:10,968 | INFO | l Console Thread | Activator
>>>> | apache.camel.impl.osgi.Activator 90 | 51 - org.apache.camel.camel-core
>>>> - 2.6.0 | Camel activator stopping
>>>> 09:48:10,968 | INFO | l Console Thread | Activator
>>>> | apache.camel.impl.osgi.Activator 92 | 51 - org.apache.camel.camel-core
>>>> - 2.6.0 | Camel activator stopped
>>>> 09:48:11,984 | INFO | l Console Thread | ContextLoaderListener
>>>> | .activator.ContextLoaderListener 449 | 44 -
>>>> org.springframework.osgi.extender - 1.2.0 | Stopping
>>>> [org.springframework.osgi.extender] bundle v.[1.2.0]
>>>> 09:48:11,984 | INFO | l Console Thread | TimerTaskExecutor
>>>> | heduling.timer.TimerTaskExecutor 179 | 38 - org.springframework.context
>>>> - 3.0.5.RELEASE | Cancelling Timer
>>>> 09:48:12,281 | INFO | l Console Thread | Console
>>>> | araf.shell.console.jline.Console 188 | 11 -
>>>> org.apache.karaf.shell.console - 2.1.3 | Exception caught while executing
>>>> 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=com.sun.org.apache.xerces.internal.dom)
>>>> at
>>>> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeatures(FeaturesServiceImpl.java:326)[19:org.apache.karaf.features.core:2.1.3]
>>>> at
>>>> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(FeaturesServiceImpl.java:254)[19:org.apache.karaf.features.core:2.1.3]
>>>> at
>>>> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(FeaturesServiceImpl.java:250)[19:org.apache.karaf.features.core:2.1.3]
>>>> at
>>>> org.apache.karaf.features.command.InstallFeatureCommand.doExecute(InstallFeatureCommand.java:51)[9:org.apache.karaf.features.command:2.1.3]
>>>> at
>>>> org.apache.karaf.features.command.FeaturesCommandSupport.doExecute(FeaturesCommandSupport.java:39)[9:org.apache.karaf.features.command:2.1.3]
>>>> at
>>>> org.apache.karaf.shell.console.OsgiCommandSupport.execute(OsgiCommandSupport.java:38)[11:org.apache.karaf.shell.console:2.1.3]
>>>> at
>>>> org.apache.felix.gogo.commands.basic.AbstractCommand.execute(AbstractCommand.java:35)[11:org.apache.karaf.shell.console:2.1.3]
>>>> at
>>>> org.apache.felix.gogo.runtime.shell.CommandProxy.execute(CommandProxy.java:50)[11:org.apache.karaf.shell.console:2.1.3]
>>>> at
>>>> org.apache.felix.gogo.runtime.shell.Closure.execute(Closure.java:229)[11:org.apache.karaf.shell.console:2.1.3]
>>>> at
>>>> org.apache.felix.gogo.runtime.shell.Closure.executeStatement(Closure.java:162)[11:org.apache.karaf.shell.console:2.1.3]
>>>> at
>>>> org.apache.felix.gogo.runtime.shell.Pipe.run(Pipe.java:101)[11:org.apache.karaf.shell.console:2.1.3]
>>>> at
>>>> org.apache.felix.gogo.runtime.shell.Closure.execute(Closure.java:79)[11:org.apache.karaf.shell.console:2.1.3]
>>>> at
>>>> org.apache.felix.gogo.runtime.shell.CommandSessionImpl.execute(CommandSessionImpl.java:71)[11:org.apache.karaf.shell.console:2.1.3]
>>>> at
>>>> org.apache.karaf.shell.console.jline.Console.run(Console.java:170)[11:org.apache.karaf.shell.console:2.1.3]
>>>> at java.lang.Thread.run(Thread.java:662)[:1.6.0_23]
>>>> Caused by: org.osgi.framework.BundleException: Unresolved constraint in
>>>> bundle org.apache.servicemix.bundles.saaj-impl [97]: Unable to resolve 97.0:
>>>> missing requirement [97.0] package;
>>>> (package=com.sun.org.apache.xerces.internal.dom)
>>>> at
>>>> org.apache.felix.framework.Felix.resolveBundle(Felix.java:3409)[org.apache.felix.framework-3.0.2.jar:]
>>>> at
>>>> org.apache.felix.framework.Felix.startBundle(Felix.java:1709)[org.apache.felix.framework-3.0.2.jar:]
>>>> at
>>>> org.apache.felix.framework.BundleImpl.start(BundleImpl.java:905)[org.apache.felix.framework-3.0.2.jar:]
>>>> at
>>>> org.apache.felix.framework.BundleImpl.start(BundleImpl.java:892)[org.apache.felix.framework-3.0.2.jar:]
>>>> at
>>>> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeatures(FeaturesServiceImpl.java:323)[19:org.apache.karaf.features.core:2.1.3]
>>>> ... 14 more
>>>>
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Thoughts about Karaf profiles / releases / growing number of
dependencies (Re: AW: AW: Problem when starting camel-cxf in karaf)
Posted by Andreas Pieber <an...@gmail.com>.
OK, there are many points in my head about this for some time now and I hope 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 distribution
and in future one for android... STOP. I think this is not the way Karaf should go.
In addition, tbh I also don't like the way client projects (such as smx) have to
tweak Karaf around to make it runnable. This makes everything complex and not
easy to use understand/start with.
Next I think the root of all evil are our configuration files. The need that 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 Karaf 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
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 don'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 may
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.xml
into the different projects: karaf-obr, karaf-ssh, ops4j-web (e.g. with jetty),
spring2, spring3, ... and create own projects for the additional components. 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 have
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 files),
system (where we drop additional .jre bundles, ...), brandings, ... With that 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 one
additional for android?!) without using the features concepts directly in the
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 only.
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 distribution.
Someone only experimenting/developing can do a
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.
>
> 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.
>
> 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..).
>
> I certainly don't have a good answer yet, but I just want to make sure
> everyone is aware of the potential problem.
>
> 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.
>
> 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
> ....
>
> Sorry for the rant. There are a bunch of unrelated things here, ...
>
> On Wed, Feb 2, 2011 at 11:29, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> > 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 them in
> >> the karaf distribution.
> >>
> >> Best regards
> >>
> >> Christian
> >>
> >>
> >> -----Ursprüngliche Nachricht-----
> >> Von: Jean-Baptiste Onofré [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üngliche 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=com.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 | FelixStartLevel | jmx
> >>> | ? ? | 20 - org.apache.aries.jmx -
> >>> 0.2.0.incubating | Starting JMX OSGi agent
> >>> 09:46:09,781 | INFO | FelixStartLevel | jmx
> >>> | ? ? | 20 - org.apache.aries.jmx -
> >>> 0.2.0.incubating | Registering MBean with ObjectName
> >>> [osgi.compendium:service=cm,version=1.3] for service with service.id [10]
> >>> 09:46:09,796 | WARN | rint Extender: 3 | BlueprintContainerImpl
> >>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
> >>> 0.2.0.incubating | Bundle org.apache.karaf.features.command is waiting for
> >>> namespace handlers
> >>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
> >>> 09:46:09,796 | WARN | rint Extender: 2 | BlueprintContainerImpl
> >>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
> >>> 0.2.0.incubating | Bundle org.apache.karaf.shell.osgi is waiting for
> >>> namespace handlers
> >>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
> >>> 09:46:09,796 | WARN | JMX OSGi Agent | jmx
> >>> | ? ? | 20 - org.apache.aries.jmx -
> >>> 0.2.0.incubating | There are no MBean servers registred, can't register
> >>> MBeans
> >>> 09:46:09,890 | WARN | rint Extender: 2 | BlueprintContainerImpl
> >>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
> >>> 0.2.0.incubating | Bundle org.apache.karaf.shell.console is waiting for
> >>> namespace handlers
> >>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0))]
> >>> 09:46:09,968 | WARN | rint Extender: 2 | BlueprintContainerImpl
> >>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
> >>> 0.2.0.incubating | Bundle org.apache.karaf.shell.dev is waiting for
> >>> namespace handlers
> >>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
> >>> 09:46:10,218 | WARN | rint Extender: 3 | BlueprintContainerImpl
> >>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
> >>> 0.2.0.incubating | Bundle org.apache.karaf.shell.ssh is waiting for
> >>> namespace handlers
> >>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
> >>> 09:46:10,234 | WARN | rint Extender: 3 | BlueprintContainerImpl
> >>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
> >>> 0.2.0.incubating | Bundle org.apache.karaf.admin.command is waiting for
> >>> namespace handlers
> >>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
> >>> 09:46:10,250 | WARN | rint Extender: 3 | BlueprintContainerImpl
> >>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
> >>> 0.2.0.incubating | Bundle org.apache.karaf.shell.commands is waiting for
> >>> namespace handlers
> >>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
> >>> 09:46:10,375 | WARN | rint Extender: 2 | BlueprintContainerImpl
> >>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
> >>> 0.2.0.incubating | Bundle org.apache.karaf.shell.packages is waiting for
> >>> namespace handlers
> >>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
> >>> 09:46:11,609 | INFO | Thread-5 | FeaturesServiceImpl
> >>> | res.internal.FeaturesServiceImpl 293 | 19 -
> >>> org.apache.karaf.features.core - 2.1.3 | Bundles to refresh:
> >>> 09:46:11,640 | INFO | rint Extender: 3 | SecurityUtils
> >>> | e.sshd.common.util.SecurityUtils 80 | 25 - sshd-core - 0.4.0 |
> >>> BouncyCastle not registered, using the default JCE provider
> >>> 09:46:11,968 | INFO | JMX OSGi Agent | jmx
> >>> | ? ? | 20 - org.apache.aries.jmx -
> >>> 0.2.0.incubating | Registering org.osgi.jmx.framework.BundleStateMBean to
> >>> MBeanServer com.sun.jmx.mbeanserver.JmxMBeanServer@6e3d60 with name
> >>> osgi.core:type=bundleState,version=1.5
> >>> 09:46:12,000 | INFO | JMX OSGi Agent | jmx
> >>> | ? ? | 20 - org.apache.aries.jmx -
> >>> 0.2.0.incubating | Registering org.osgi.jmx.framework.ServiceStateMBean to
> >>> MBeanServer com.sun.jmx.mbeanserver.JmxMBeanServer@6e3d60 with name
> >>> osgi.core:type=serviceState,version=1.5
> >>> 09:46:12,000 | INFO | JMX OSGi Agent | jmx
> >>> | ? ? | 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=framework,version=1.5
> >>> 09:46:12,031 | INFO | JMX OSGi Agent | jmx
> >>> | ? ? | 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=cm,version=1.3
> >>> 09:46:12,031 | INFO | JMX OSGi Agent | jmx
> >>> | ? ? | 20 - org.apache.aries.jmx -
> >>> 0.2.0.incubating | Registering org.osgi.jmx.framework.PackageStateMBean to
> >>> MBeanServer com.sun.jmx.mbeanserver.JmxMBeanServer@6e3d60 with name
> >>> osgi.core:type=packageState,version=1.5
> >>> 09:48:08,234 | INFO | l Console Thread | FeaturesServiceImpl
> >>> | res.internal.FeaturesServiceImpl 293 | 19 -
> >>> org.apache.karaf.features.core - 2.1.3 | Bundles to refresh:
> >>> 09:48:08,656 | INFO | l Console Thread | ContextLoaderListener
> >>> | .activator.ContextLoaderListener 356 | 44 -
> >>> org.springframework.osgi.extender - 1.2.0 | Starting
> >>> [org.springframework.osgi.extender] bundle v.[1.2.0]
> >>> 09:48:08,781 | INFO | l Console Thread | ExtenderConfiguration
> >>> | al.support.ExtenderConfiguration 150 | 44 -
> >>> org.springframework.osgi.extender - 1.2.0 | No custom extender configuration
> >>> detected; using defaults...
> >>> 09:48:08,781 | INFO | l Console Thread | TimerTaskExecutor
> >>> | heduling.timer.TimerTaskExecutor 106 | 38 - org.springframework.context
> >>> - 3.0.5.RELEASE | Initializing Timer
> >>> 09:48:09,281 | INFO | l Console Thread | Activator
> >>> | apache.camel.impl.osgi.Activator 83 | 51 - org.apache.camel.camel-core
> >>> - 2.6.0 | Camel activator starting
> >>> 09:48:09,312 | INFO | l Console Thread | Activator
> >>> | apache.camel.impl.osgi.Activator 86 | 51 - org.apache.camel.camel-core
> >>> - 2.6.0 | Camel activator started
> >>> 09:48:10,968 | INFO | l Console Thread | Activator
> >>> | apache.camel.impl.osgi.Activator 90 | 51 - org.apache.camel.camel-core
> >>> - 2.6.0 | Camel activator stopping
> >>> 09:48:10,968 | INFO | l Console Thread | Activator
> >>> | apache.camel.impl.osgi.Activator 92 | 51 - org.apache.camel.camel-core
> >>> - 2.6.0 | Camel activator stopped
> >>> 09:48:11,984 | INFO | l Console Thread | ContextLoaderListener
> >>> | .activator.ContextLoaderListener 449 | 44 -
> >>> org.springframework.osgi.extender - 1.2.0 | Stopping
> >>> [org.springframework.osgi.extender] bundle v.[1.2.0]
> >>> 09:48:11,984 | INFO | l Console Thread | TimerTaskExecutor
> >>> | heduling.timer.TimerTaskExecutor 179 | 38 - org.springframework.context
> >>> - 3.0.5.RELEASE | Cancelling Timer
> >>> 09:48:12,281 | INFO | l Console Thread | Console
> >>> | araf.shell.console.jline.Console 188 | 11 -
> >>> org.apache.karaf.shell.console - 2.1.3 | Exception caught while executing
> >>> 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=com.sun.org.apache.xerces.internal.dom)
> >>> at
> >>> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeatures(FeaturesServiceImpl.java:326)[19:org.apache.karaf.features.core:2.1.3]
> >>> at
> >>> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(FeaturesServiceImpl.java:254)[19:org.apache.karaf.features.core:2.1.3]
> >>> at
> >>> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(FeaturesServiceImpl.java:250)[19:org.apache.karaf.features.core:2.1.3]
> >>> at
> >>> org.apache.karaf.features.command.InstallFeatureCommand.doExecute(InstallFeatureCommand.java:51)[9:org.apache.karaf.features.command:2.1.3]
> >>> at
> >>> org.apache.karaf.features.command.FeaturesCommandSupport.doExecute(FeaturesCommandSupport.java:39)[9:org.apache.karaf.features.command:2.1.3]
> >>> at
> >>> org.apache.karaf.shell.console.OsgiCommandSupport.execute(OsgiCommandSupport.java:38)[11:org.apache.karaf.shell.console:2.1.3]
> >>> at
> >>> org.apache.felix.gogo.commands.basic.AbstractCommand.execute(AbstractCommand.java:35)[11:org.apache.karaf.shell.console:2.1.3]
> >>> at
> >>> org.apache.felix.gogo.runtime.shell.CommandProxy.execute(CommandProxy.java:50)[11:org.apache.karaf.shell.console:2.1.3]
> >>> at
> >>> org.apache.felix.gogo.runtime.shell.Closure.execute(Closure.java:229)[11:org.apache.karaf.shell.console:2.1.3]
> >>> at
> >>> org.apache.felix.gogo.runtime.shell.Closure.executeStatement(Closure.java:162)[11:org.apache.karaf.shell.console:2.1.3]
> >>> at
> >>> org.apache.felix.gogo.runtime.shell.Pipe.run(Pipe.java:101)[11:org.apache.karaf.shell.console:2.1.3]
> >>> at
> >>> org.apache.felix.gogo.runtime.shell.Closure.execute(Closure.java:79)[11:org.apache.karaf.shell.console:2.1.3]
> >>> at
> >>> org.apache.felix.gogo.runtime.shell.CommandSessionImpl.execute(CommandSessionImpl.java:71)[11:org.apache.karaf.shell.console:2.1.3]
> >>> at
> >>> org.apache.karaf.shell.console.jline.Console.run(Console.java:170)[11:org.apache.karaf.shell.console:2.1.3]
> >>> at java.lang.Thread.run(Thread.java:662)[:1.6.0_23]
> >>> Caused by: org.osgi.framework.BundleException: Unresolved constraint in
> >>> bundle org.apache.servicemix.bundles.saaj-impl [97]: Unable to resolve 97.0:
> >>> missing requirement [97.0] package;
> >>> (package=com.sun.org.apache.xerces.internal.dom)
> >>> at
> >>> org.apache.felix.framework.Felix.resolveBundle(Felix.java:3409)[org.apache.felix.framework-3.0.2.jar:]
> >>> at
> >>> org.apache.felix.framework.Felix.startBundle(Felix.java:1709)[org.apache.felix.framework-3.0.2.jar:]
> >>> at
> >>> org.apache.felix.framework.BundleImpl.start(BundleImpl.java:905)[org.apache.felix.framework-3.0.2.jar:]
> >>> at
> >>> org.apache.felix.framework.BundleImpl.start(BundleImpl.java:892)[org.apache.felix.framework-3.0.2.jar:]
> >>> at
> >>> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeatures(FeaturesServiceImpl.java:323)[19:org.apache.karaf.features.core:2.1.3]
> >>> ... 14 more
> >>>
> >
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
Re: Thoughts about Karaf profiles / releases / growing number of
dependencies (Re: AW: AW: Problem when starting camel-cxf in karaf)
Posted by Andreas Pieber <an...@gmail.com>.
+1; I like the idea but I would propose the following modifications
1) rename featurelist to repository (or something like this)
2) downloadall, possibleurls, ... should be commands of repository I think
3) I think this with the versions could be handled if we have some repository
entries only pointing to the root folder of a mvn repo; we can use the metadata
file then to determine the real versions
kind regards,
andreas
On Fri, Feb 04, 2011 at 08:11:46AM +0100, Christian Schneider wrote:
>
> Am 04.02.2011 00:53, schrieb David Jencks:
> >
> >It seems to me that some of these ideas are not infinitely extensible. If everyone and their dog set up their projects to generate a karaf feature/kar we won't be able to track all of them. This may not be a problem for a long time though :-)
> >
> >SImilarly I'm not sure what you mean by "all installable features". A kar file gives you the option of installing any number of bundles and config info and features from a single file. These are now easy to create with the feature-maven-plugin. Does this seem sufficiently useful?
> >
> >thanks
> >david jencks
>
> Hi David,
>
> What I meant with all installable feature lists. Is that we provide
> a list of possible features.xml url. Ideally without the version
> number. Something like:
> karaf=>mvn:org.apache.karaf/apache-karaf
> activemq=>mvn:org.apache.activemq/activemq-karaf
> camel=>mvn:org.apache.camel.karaf/apache-camel
> ...
>
> So this list could be that base for a command line extension that
> allows to browse through the lists and versions. So with the list I
> provided you could do:
> > features:possibleurl
> karaf
> activemq
> camel
>
> > featurelist:possibleurl camel
> camel 2.5.0
> camel 2.6.0
> ...
>
> >features:addurl camel 2.5.0
> >features:addurl activemq 5.4.2
> >features:addurl karaf 2.1.3
>
> >features:listurl
> mvn:org.apache.karaf/apache-karaf/2.1.3/xml/features valid
> mvn:org.apache.camel.karaf/apache-camel/2.6.0/xml/features valid
> mvn:org.apache.activemq/activemq-karaf/5.4.2/xml/features valid
>
> >features:downloadall
> This would download all features from all the features.xml files
> above into either one repository e.g. contrib or into one repository
> for each of the files. So after this command people could go offline
> and
> later install and uninstall all features they want without internet
> connection. This part is very important as many companies do not
> allow internet access inside their networks. Still the admins will
> want to be flexible enough
> to install and uninstall features.
>
> So the idea about this would be that people don´t have to remember
> the mvn urls of all the features.xml files out there. Of course it
> won´t be possible to track all of them but I think it would be
> enough
> to have the important ones. By not adding the version to the list
> karaf could be flexible enough to find e.g. camel 2.7.0 as soon as
> it is released.
>
> Best regards
>
> Christian
>
>
> >
> >>Best regards
> >>
> >>Christian
> >>
> >>--
> >>----
> >>http://www.liquid-reality.de
> >>
> >>
> >>
> >>Am 04.02.2011 00:07, schrieb Guillaume Nodet:
> >>>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.
> >>>
> >>>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.
> >>>
> >>>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..).
> >>>
> >>>I certainly don't have a good answer yet, but I just want to make sure
> >>>everyone is aware of the potential problem.
> >>>
> >>>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.
> >>>
> >>>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
> >>>....
> >>>
> >>>Sorry for the rant. There are a bunch of unrelated things here, ...
> >>>
> >>>On Wed, Feb 2, 2011 at 11:29, Jean-Baptiste Onofré<jb...@nanthrax.net> wrote:
> >>>>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 them in
> >>>>>the karaf distribution.
> >>>>>
> >>>>>Best regards
> >>>>>
> >>>>>Christian
> >>>>>
> >>>>>
> >>>>>-----Ursprüngliche Nachricht-----
> >>>>>Von: Jean-Baptiste Onofré [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
> >>>>>>
> >
>
> --
> ----
> http://www.liquid-reality.de
>
Re: Thoughts about Karaf profiles / releases / growing number of
dependencies (Re: AW: AW: Problem when starting camel-cxf in karaf)
Posted by Christian Schneider <ch...@die-schneider.net>.
Am 04.02.2011 00:53, schrieb David Jencks:
>
> It seems to me that some of these ideas are not infinitely extensible. If everyone and their dog set up their projects to generate a karaf feature/kar we won't be able to track all of them. This may not be a problem for a long time though :-)
>
> SImilarly I'm not sure what you mean by "all installable features". A kar file gives you the option of installing any number of bundles and config info and features from a single file. These are now easy to create with the feature-maven-plugin. Does this seem sufficiently useful?
>
> thanks
> david jencks
Hi David,
What I meant with all installable feature lists. Is that we provide a
list of possible features.xml url. Ideally without the version number.
Something like:
karaf=>mvn:org.apache.karaf/apache-karaf
activemq=>mvn:org.apache.activemq/activemq-karaf
camel=>mvn:org.apache.camel.karaf/apache-camel
...
So this list could be that base for a command line extension that allows
to browse through the lists and versions. So with the list I provided
you could do:
> features:possibleurl
karaf
activemq
camel
> featurelist:possibleurl camel
camel 2.5.0
camel 2.6.0
...
>features:addurl camel 2.5.0
>features:addurl activemq 5.4.2
>features:addurl karaf 2.1.3
>features:listurl
mvn:org.apache.karaf/apache-karaf/2.1.3/xml/features valid
mvn:org.apache.camel.karaf/apache-camel/2.6.0/xml/features valid
mvn:org.apache.activemq/activemq-karaf/5.4.2/xml/features valid
>features:downloadall
This would download all features from all the features.xml files above
into either one repository e.g. contrib or into one repository for each
of the files. So after this command people could go offline and
later install and uninstall all features they want without internet
connection. This part is very important as many companies do not allow
internet access inside their networks. Still the admins will want to be
flexible enough
to install and uninstall features.
So the idea about this would be that people don´t have to remember the
mvn urls of all the features.xml files out there. Of course it won´t be
possible to track all of them but I think it would be enough
to have the important ones. By not adding the version to the list karaf
could be flexible enough to find e.g. camel 2.7.0 as soon as it is released.
Best regards
Christian
>
>> Best regards
>>
>> Christian
>>
>> --
>> ----
>> http://www.liquid-reality.de
>>
>>
>>
>> Am 04.02.2011 00:07, schrieb Guillaume Nodet:
>>> 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.
>>>
>>> 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.
>>>
>>> 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..).
>>>
>>> I certainly don't have a good answer yet, but I just want to make sure
>>> everyone is aware of the potential problem.
>>>
>>> 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.
>>>
>>> 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
>>> ....
>>>
>>> Sorry for the rant. There are a bunch of unrelated things here, ...
>>>
>>> On Wed, Feb 2, 2011 at 11:29, Jean-Baptiste Onofré<jb...@nanthrax.net> wrote:
>>>> 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 them in
>>>>> the karaf distribution.
>>>>>
>>>>> Best regards
>>>>>
>>>>> Christian
>>>>>
>>>>>
>>>>> -----Ursprüngliche Nachricht-----
>>>>> Von: Jean-Baptiste Onofré [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
>>>>>>
>
--
----
http://www.liquid-reality.de
Re: Thoughts about Karaf profiles / releases / growing number of
dependencies (Re: AW: AW: Problem when starting camel-cxf in karaf)
Posted by "Jamie G." <ja...@gmail.com>.
One of the nice things about releasing Karaf has been that it's pretty
straight forward - if we start to break it up into multiple releases
then yes we'd gain flexibility at the cost of some complexity. Each
Karaf release will then become a collection of parts that we deem to
work well together, something akin to SMX releases. While this is
manageable, is it preferable? As a monolith do we have more incentive
to keep things small/compact, where as separate pieces things may
collectively grow larger?
Jamie
On Thu, Feb 3, 2011 at 8:23 PM, David Jencks <da...@yahoo.com> wrote:
>
> On Feb 3, 2011, at 3:27 PM, Christian Schneider wrote:
>
>> Hi Guillaume and the whole Karaf team,
>>
>> as I was involved in the discussion I would like to provide my point of view.
>>
>> I really like that karaf is as small as it is and it should stay this way. The only problem that I had was that the jre.properties deployed with karaf did not work with the
>> camel-cxf feature. So how can this be solved? One way is simply better documentation on the karaf or camel wiki. Additionally the jre.properties from servicemix
>> could be delivered in the karaf distro as e.g. jre.properties.servicemix or something. So it is easier for people to switch them.
>>
>> It would also be nice to have some feature urls already in karaf so people do not need to search them. They could be either directly included or should be easily activated. So for example karaf could know where the feature xmls of camel and activemq are in maven and then people could do something like: "features:addurl camel 2.6.0" perhaps even with content assist. On the other hand a wiki page with the list of the mvn: urls for all important feature xmls would already be good enough.
>>
>> I have not followed the profiles discussion but the current state of having feature urls and being able to install them with some commands sounds easy enough for me.
>>
>> The only thing that could be easier is installing features without an internet connection. It would be nice to have some command to download all installable features into a karaf directory so afterwards
>> no internet connection is necessary. The camel feature plugin does this for distributions but it would be nice if users could do this simply from the command line.
>>
>
> It seems to me that some of these ideas are not infinitely extensible. If everyone and their dog set up their projects to generate a karaf feature/kar we won't be able to track all of them. This may not be a problem for a long time though :-)
>
> SImilarly I'm not sure what you mean by "all installable features". A kar file gives you the option of installing any number of bundles and config info and features from a single file. These are now easy to create with the feature-maven-plugin. Does this seem sufficiently useful?
>
> thanks
> david jencks
>
>
>> Best regards
>>
>> Christian
>>
>> --
>> ----
>> http://www.liquid-reality.de
>>
>>
>>
>> Am 04.02.2011 00:07, schrieb Guillaume Nodet:
>>> 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.
>>>
>>> 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.
>>>
>>> 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..).
>>>
>>> I certainly don't have a good answer yet, but I just want to make sure
>>> everyone is aware of the potential problem.
>>>
>>> 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.
>>>
>>> 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
>>> ....
>>>
>>> Sorry for the rant. There are a bunch of unrelated things here, ...
>>>
>>> On Wed, Feb 2, 2011 at 11:29, Jean-Baptiste Onofré<jb...@nanthrax.net> wrote:
>>>> 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 them in
>>>>> the karaf distribution.
>>>>>
>>>>> Best regards
>>>>>
>>>>> Christian
>>>>>
>>>>>
>>>>> -----Ursprüngliche Nachricht-----
>>>>> Von: Jean-Baptiste Onofré [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
>>>>>>
>>
>
>
Re: Thoughts about Karaf profiles / releases / growing number of dependencies (Re: AW: AW: Problem when starting camel-cxf in karaf)
Posted by David Jencks <da...@yahoo.com>.
On Feb 3, 2011, at 3:27 PM, Christian Schneider wrote:
> Hi Guillaume and the whole Karaf team,
>
> as I was involved in the discussion I would like to provide my point of view.
>
> I really like that karaf is as small as it is and it should stay this way. The only problem that I had was that the jre.properties deployed with karaf did not work with the
> camel-cxf feature. So how can this be solved? One way is simply better documentation on the karaf or camel wiki. Additionally the jre.properties from servicemix
> could be delivered in the karaf distro as e.g. jre.properties.servicemix or something. So it is easier for people to switch them.
>
> It would also be nice to have some feature urls already in karaf so people do not need to search them. They could be either directly included or should be easily activated. So for example karaf could know where the feature xmls of camel and activemq are in maven and then people could do something like: "features:addurl camel 2.6.0" perhaps even with content assist. On the other hand a wiki page with the list of the mvn: urls for all important feature xmls would already be good enough.
>
> I have not followed the profiles discussion but the current state of having feature urls and being able to install them with some commands sounds easy enough for me.
>
> The only thing that could be easier is installing features without an internet connection. It would be nice to have some command to download all installable features into a karaf directory so afterwards
> no internet connection is necessary. The camel feature plugin does this for distributions but it would be nice if users could do this simply from the command line.
>
It seems to me that some of these ideas are not infinitely extensible. If everyone and their dog set up their projects to generate a karaf feature/kar we won't be able to track all of them. This may not be a problem for a long time though :-)
SImilarly I'm not sure what you mean by "all installable features". A kar file gives you the option of installing any number of bundles and config info and features from a single file. These are now easy to create with the feature-maven-plugin. Does this seem sufficiently useful?
thanks
david jencks
> Best regards
>
> Christian
>
> --
> ----
> http://www.liquid-reality.de
>
>
>
> Am 04.02.2011 00:07, schrieb Guillaume Nodet:
>> 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.
>>
>> 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.
>>
>> 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..).
>>
>> I certainly don't have a good answer yet, but I just want to make sure
>> everyone is aware of the potential problem.
>>
>> 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.
>>
>> 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
>> ....
>>
>> Sorry for the rant. There are a bunch of unrelated things here, ...
>>
>> On Wed, Feb 2, 2011 at 11:29, Jean-Baptiste Onofré<jb...@nanthrax.net> wrote:
>>> 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 them in
>>>> the karaf distribution.
>>>>
>>>> Best regards
>>>>
>>>> Christian
>>>>
>>>>
>>>> -----Ursprüngliche Nachricht-----
>>>> Von: Jean-Baptiste Onofré [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
>>>>>
>
Re: Thoughts about Karaf profiles / releases / growing number of
dependencies (Re: AW: AW: Problem when starting camel-cxf in karaf)
Posted by Christian Schneider <ch...@die-schneider.net>.
Hi Guillaume and the whole Karaf team,
as I was involved in the discussion I would like to provide my point of
view.
I really like that karaf is as small as it is and it should stay this
way. The only problem that I had was that the jre.properties deployed
with karaf did not work with the
camel-cxf feature. So how can this be solved? One way is simply better
documentation on the karaf or camel wiki. Additionally the
jre.properties from servicemix
could be delivered in the karaf distro as e.g. jre.properties.servicemix
or something. So it is easier for people to switch them.
It would also be nice to have some feature urls already in karaf so
people do not need to search them. They could be either directly
included or should be easily activated. So for example karaf could know
where the feature xmls of camel and activemq are in maven and then
people could do something like: "features:addurl camel 2.6.0" perhaps
even with content assist. On the other hand a wiki page with the list of
the mvn: urls for all important feature xmls would already be good enough.
I have not followed the profiles discussion but the current state of
having feature urls and being able to install them with some commands
sounds easy enough for me.
The only thing that could be easier is installing features without an
internet connection. It would be nice to have some command to download
all installable features into a karaf directory so afterwards
no internet connection is necessary. The camel feature plugin does this
for distributions but it would be nice if users could do this simply
from the command line.
Best regards
Christian
--
----
http://www.liquid-reality.de
Am 04.02.2011 00:07, schrieb Guillaume Nodet:
> 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.
>
> 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.
>
> 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..).
>
> I certainly don't have a good answer yet, but I just want to make sure
> everyone is aware of the potential problem.
>
> 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.
>
> 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
> ....
>
> Sorry for the rant. There are a bunch of unrelated things here, ...
>
> On Wed, Feb 2, 2011 at 11:29, Jean-Baptiste Onofré<jb...@nanthrax.net> wrote:
>> 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 them in
>>> the karaf distribution.
>>>
>>> Best regards
>>>
>>> Christian
>>>
>>>
>>> -----Ursprüngliche Nachricht-----
>>> Von: Jean-Baptiste Onofré [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
>>>>