Installing camel-spring fails on Karaf 2.2.4. Following the
documentation Quick Start, Deploy a Sample Application but using
Camel 2.8.1 instead of 2.7.0 (note that 2.7.0 fails with the same error):
features:addurl mvn:org.apache.camel/camel-example-osgi/2.8.1/xml/features
features:install
).
For previous Camel versions you have to use Karaf 2.2.2.
Regards
JB
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://wwx.talend.com
- Reply message -
From: Raman Gupta rocketra...@gmail.com
To: user@karaf.apache.org
Subject: camel-spring fails
surprised the Blueprint spec developers didn't
consider interop with existing DI frameworks as a first class spec
item. I suppose such functionality could still be implemented as a
Blueprint extension for each DI framework.
Regards,
Raman Gupta
VIVO Systems
http://vivosys.com
).
--
Raman Gupta
VIVO Systems
http://vivosys.com
On 11/01/2011 09:01 AM, Guillaume Nodet wrote:
You can use OSGi services for that. OSGi services can be exported and
imported irrespective of the underlying technology used.
On Tue, Nov 1, 2011 at 13:35, Raman Gupta rocketra...@gmail.com
Spring and Blueprint namespaces. There is an example shown here:
http://static.springsource.org/osgi/docs/2.0.0.M1/reference/html-single/#blueprint:differences:xml
However, Karaf doesn't support DM 2 / Gemini at this time AFAIK.
--
Raman Gupta
VIVO Systems
http://vivosys.com
beans, util, p, Spring Expression
Language (SpEL) and the task namespace introduced in Spring 3.x, and
Spring DM [ed: this should say Blueprint] namespace.
--
Raman Gupta
VIVO Systems
http://vivosys.com
decided to move to Karaf
for my current project. But I'd definitely like to see Gemini on Karaf.
I believe your other scenario (camel, blueprint, spring contexts in
the same bundle) is not possible with Aries Blueprint, but is possible
with Gemini Blueprint.
--
Raman Gupta
VIVO Systems
http
AspectJ LTW solution for Felix?
2) Does anyone have any experience with Equinox Aspects on top of
Karaf with Equinox?
Regards,
Raman Gupta
Principal
VIVO Systems
I see that Karaf has a dev:watch command, but I also note that this
does not refresh the bundles.
Is there a way to tell Karaf to automatically refresh the changed
bundle as well?
Thanks,
Raman
updates bundle if source location has been
changed. You don't need to execute a refresh. It should back to Active
state right after update without need to do refresh.
Łukasz Dywicki
--
Code-House
http://code-house.org
Wiadomość napisana przez Raman Gupta w dniu 2012-01-12, o godz. 21:48
Actually, as per the bug report, this applies even to the first WAB
when using the error-code element rather than exception-type.
Is there a work-around for this short of generating the error page
from directly within the app?
Regards,
Raman
On 03/07/2012 02:59 PM, Achim Nierbeck wrote:
Hi
On 03/12/2012 08:48 AM, Guillaume Yziquel wrote:
Le Monday 12 Mar 2012 à 12:51:17 (+0100), Gert Vanthienen a écrit :
L.S.,
Hi.
The Slang project is something I started quite a while ago, but that
hasn't been developed any further. The goal was not only to support
Slang, but
Just one more data point... we are using Karaf 2.2.4 on top of JDK7,
with sources compiled using JDK7 without any problem so far.
Regards,
Raman
Principal
VIVO Systems
On 03/28/2012 03:58 PM, Andreas Pieber wrote:
In detail this depends on the details of your setup. Nevertheless, in
general
Another interested party re. Gemini-Blueprint here...
Gemini-blueprint offers integration with Spring application contexts
whereas Aries Blueprint does not. Without integration with Spring
and/or Guice, I'm not sure how useful Aries can really be... The DI
capabilities of raw Blueprint are ok for
I just upgraded to Karaf 2.2.7 from Karaf 2.2.4 and noticed that now
the Spring DM web extender and pax web extender's no longer run in the
correct order.
The Spring-DM extender needs to process the bundle *before* the PaxWeb
extender, since until the app context is created by Spring-DM it is a
, but iirc that's not the case here.
On Mon, Jun 25, 2012 at 6:21 AM, Raman Gupta rocketra...@gmail.com wrote:
I just upgraded to Karaf 2.2.7 from Karaf 2.2.4 and noticed that now
the Spring DM web extender and pax web extender's no longer run in the
correct order.
The Spring-DM extender needs
one to achieve obviously, but will be
really tied to the extenders your using and how they behave, as if
both are started synchronously, you won't really have any way to do
some synchronization here, but iirc that's not the case here.
On Mon, Jun 25, 2012 at 6:21 AM, Raman Gupta rocketra
am I
supposed to do that without using Spring-DM or Gemini Blueprint, or
doing it manually using the OSGi api's?
On Tue, Jun 26, 2012 at 1:23 AM, Raman Gupta rocketra...@gmail.com wrote:
On 06/25/2012 03:21 AM, Guillaume Nodet wrote:
That's a quite big problem and I'm not really aware of any way
:
org.springframework.osgi.web.context.support.OsgiBundleXmlWebApplicationContext
That's exactly what I'm doing... and it is what works perfectly with
2.2.4 but doesn't work with Karaf 2.2.7.
On Tue, Jun 26, 2012 at 4:42 PM, Raman Gupta rocketra...@gmail.com wrote:
On 06/26/2012 07:17 AM, Guillaume Nodet wrote:
If you use
I have an application in which, when it's given the stop command, I'd
like to finish some work in progress before shutting down bundle 0.
This is because the bundle shutdown starts prematurely shutting down
services and such that are necessary for the work to complete.
For now, I've implemented
On 11/26/2012 02:33 PM, Raman Gupta wrote:
Ideally, Karaf would have a ShutdownHook interface/service I could
implement in my bundles -- for each one of these registered, Karaf
would execute them before stopping the framework bundles. If someone
could give me some starting pointers, I could
:
$ jmap -heap 27384
[...]
PS Perm Generation
used = 88594176 (84.489990234375MB)
I haven't tried this with Felix, but is this a perm gen leak, or an
unavoidable consequence of the mechanism dev:restart uses?
Regards,
Raman Gupta
http://vivosys.com
--
View this message in context:
http
we can do something in
Karaf,
I will take a look.
Regards
JB
On 01/31/2013 01:42 AM, Raman Gupta wrote:
If using dev:restart with Karaf 2.2.9 with Equinox, the size of the
permanent
generation increases drastically:
Permanent generation on initial start:
$ jmap -heap 27384
[...]
PS
Congrats!
Now, if someone could only explain to me what a "dual polymorphic
container" is! :-)
Regards,
Raman
On 02/04/2016 10:31 AM, Jean-Baptiste Onofré wrote:
> Hi all,
>
> as you may have seen that the new Karaf website is now online.
>
> Don't hesitate to create Jira (with website
t; Regards
> JB
>
> On 01/28/2016 04:27 PM, Raman Gupta wrote:
>> JB, no problem, thanks for your help. Nope that does not work. All my
>> features that use wrap already have wrap declared.
>>
>> I think I have this narrowed down a bit more. I eliminated any
&g
Was the pom below helpful in any way to understanding this issue?
Thanks,
Raman
On 01/26/2016 01:00 PM, Raman Gupta wrote:
> Here you go:
>
> http://pastebin.com/4F13xSp9
>
> Regards,
> Raman
>
> On 01/26/2016 12:40 PM, Jean-Baptiste Onofré wrote:
>> Can you sha
is in
the dependencies with compile scope.
A good working demo:
https://github.com/rocketraman/test-karaf-verify/blob/master/test-verify/pom.xml
Regards,
Raman
On 01/28/2016 11:33 AM, Raman Gupta wrote:
> Thanks JB, here is a simple test case:
>
> https://github.com/rocketraman/t
I'm loading the feature spring-dm-web into a vanilla karaf 4.0.4
instance. Karaf insists on loading the Spring 3.1.4 bundles even
though the spring-dm-web feature references a Spring range that allows
a 3.2 version:
Feature depends on:
spring-dm 0.0.0
spring-web [2.5.6,4)
http 0.0.0
Why is
alled)
> that limit the range to Spring 3.1.x.
>
> What features do you have installed ?
>
> Regards
> JB
>
> On 01/31/2016 12:48 PM, Christian Schneider wrote:
>> From the error message I would say that the karaf feature core bundle
>> limits th
features. So, let me check the resolver messages.
>
> Regards
> JB
>
>
> On 02/01/2016 04:26 PM, Raman Gupta wrote:
>>
>> I just tried it again on a totally vanilla karaf instance, newly
>> decompressed from the tar.gz:
>>
>> feature:install spr
an-Baptiste Onofré wrote:
> Hi Raman,
>
> sorry I missed your message.
>
> As your com.myorg* feature needs wrap, and you validate transitive,
> wrap feature should be part of the verify list/definition.
>
> Your features should define the wrap feature as dependenc
You don't need to add the verify execution if you don't want it
(though I would recommend it).
I find the karaf-maven-plugin is poorly documented, and out of date to
some extent.
My final (working) assembly pom looks like this (remove the verify
execution if you don't want it, and you probably
config.properties, so the default is being
used, which should load the wrap feature.
Any ideas?
Regards,
Raman Gupta
4.0.4
> kar
>
>
> org.apache.karaf.features
> standard
> 4.0.4
> features
> xml
>
>
> in your pom.xml.
>
> Is it the case ?
>
> Thanks,
> Regards
> JB
>
> On 01/26/2016 06:18 PM, Ram
rap)(type=karaf.feature)(version>=0.0.0))"
Regards,
Raman
On 01/26/2016 12:39 PM, Raman Gupta wrote:
> I didn't, but adding those does not help. I also tried adding
> slf4j-api >= 1.6.0 as suggested by the error message. Still fails with
> the same error. I tried both the pom se
Here you go:
http://pastebin.com/4F13xSp9
Regards,
Raman
On 01/26/2016 12:40 PM, Jean-Baptiste Onofré wrote:
> Can you share your pom.xml ?
>
> Thanks,
> Regards
> JB
>
> On 01/26/2016 06:39 PM, Raman Gupta wrote:
>> I didn't, but adding those does not help. I als
does use the wrap url-handler,
> make sure you have a dependency on the wrap feature in your feature
> and mark it as prerequisite=true
>
> regards, Achim
>
>
> 2016-01-26 19:00 GMT+01:00 Raman Gupta <rocketra...@gmail.com
> <mailto:rocketra...@gmail.com>>:
>
My project builds assembly modules and then in another module runs the
karaf-maven-plugin.
This works fine when using the "install" goal. However, when using the
"package" goal it does not: package does not install the assemblies
into the local maven repo, and karaf-maven-plugin fails with a
I was having this (or a similar) issue too:
https://issues.apache.org/jira/browse/KARAF-4306
has a reproducible test case.
My workaround was to copy the correct version of the Spring features from
the Karaf source into my own feature file.
Regards,
Raman
--
View this message in context:
39 matches
Mail list logo
