Karaf maven plugin package vs install

[Raman Gupta]

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
resolution error (or even worse, it works but pulls in an older
snapshot version of the features from ~/.m2).

Should the karaf-maven-plugin be looking at the reactor artifacts
(target/whatever of the dependent modules) rather than the the
installed artifacts (.m2/repository/whatever of the dependent modules)?

Regards,
Raman

Re: Limit Spring Jars Brought In by Spring Feature In Custom Distribution

[Raman Gupta]

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: 
http://karaf.922171.n3.nabble.com/Re-Limit-Spring-Jars-Brought-In-by-Spring-Feature-In-Custom-Distribution-tp4045684p4045697.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: Issue building with karaf-maven-plugin

[Raman Gupta]

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 don't need the spring
blacklist or dependency):

https://gist.github.com/rocketraman/914c55ab8577c95d3408

HTH

Regards,
Raman


On 02/29/2016 01:44 PM, David Daniel wrote:
> I was able to get around the log compendium issue by using the link
> provided but now I am hitting a configuration managment one.  Is there
> a way to just disable the verify phase of the karaf-maven-plugin and
> go straight to package.
> 
> [ERROR] Failed to execute goal
> org.apache.karaf.tooling:karaf-maven-plugin:4.0.4:assembly
> (default-assembly) on project server-installer: Unable to build
> assembly: Unable to resolve root: missing requirement [root]
> osgi.identity; osgi.identity=aardvarkconfigurerbundles;
> type=karaf.feature; version=0;
> filter:="(&(osgi.identity=aardvarkconfigurerbundles)(type=karaf.feature)(version>=0.0.0))"
> [caused by: Unable to resolve aardvarkconfigurerbundles/1.0.0: missing
> requirement [aardvarkconfigurerbundles/1.0.0] osgi.identity;
> osgi.identity=osgi.enroute.configurer.simple.provider;
> type=osgi.bundle; version="[1.2.2.201509211431,1.2.2.201509211431]";
> resolution:=mandatory [caused by: Unable to resolve
> osgi.enroute.configurer.simple.provider/1.2.2.201509211431: missing
> requirement
> [osgi.enroute.configurer.simple.provider/1.2.2.201509211431]
> osgi.wiring.package;
> filter:="(&(osgi.wiring.package=org.osgi.service.cm
> )(version>=1.5.0)(!(version>=2.0.0)))"]]
> -> [Help 1]
> 
> 
> On Sun, Feb 28, 2016 at 3:05 PM, David Daniel
> > wrote:
> 
> When I added a prerequiste to the log feature I hit this error
> 
> [ERROR] Failed to execute goal
> org.apache.karaf.tooling:karaf-maven-plugin:4.0.4:assembly
> (default-assembly) on project server-installer: Unable to build
> assembly: Unable to resolve root: missing requirement [root]
> osgi.identity; osgi.identity=log; type=karaf.feature; version=0;
> filter:="(&(osgi.identity=log)(type=karaf.feature)(version>=0.0.0))"
> [caused by: Unable to resolve log/4.0.4: missing requirement
> [log/4.0.4] osgi.identity;
> osgi.identity=org.apache.karaf.log.core; type=osgi.bundle;
> version="[4.0.4,4.0.4]"; resolution:=mandatory [caused by: Unable
> to resolve org.apache.karaf.log.core/4.0.4: missing requirement
> [org.apache.karaf.log.core/4.0.4] osgi.wiring.package;
> 
> filter:="(&(osgi.wiring.package=org.ops4j.pax.logging.spi)(version>=1.8.0)(!(version>=2.0.0)))"]]
> -> [Help 1]
> 
> Looking that up I saw ramens post that pointed here
> 
> 
> https://github.com/rocketraman/test-karaf-verify/blob/master/test-verify/pom.xml
> 
> I I tried adding the execution but it did not help
> 
> 
> verify
> process-resources
> 
> verify
> 
> 
> 1.8
> true
> 
>
> 
> mvn:org.apache.karaf.features/framework/${karaf.version}/xml/features
>
> 
> mvn:${project.groupId}/features/${project.version}/xml/features
> 
> 
>
> aardvarkfelixbundles
> 
>
> org.apache.karaf.features:framework
> 
> framework
> 
> 
> 
> 
> 
> 
> On Sun, Feb 28, 2016 at 2:06 PM, Jean-Baptiste Onofré
> > wrote:
> 
> Hi
> 
> Your feature should just depends to the log feature: thanks to
> that the resolver will find the expected packages for the verify.
> 
> Regards 
> JB 
> 
> 
> 
> Sent from my Samsung device
> 
> 
>  Original message 
> From: David Daniel  >
> Date: 28/02/2016 18:01 (GMT+01:00)
> To: user@karaf.apache.org 
> Subject: Issue building with karaf-maven-plugin
> 
> I am having an issue building with karaf-maven-plugin 4.0.4. 
> I never had it working with a previous version and I am just
> trying to start setting it up so it is 

Re: [ANN] New Karaf website online

[Raman Gupta]

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 component) if you see some
> broken links and rendering issue.
> 
> Thanks !
> Regards
> JB

[SOLVED] Re: Features validation: cannot find wrap

[Raman Gupta]

Got this figured out with some help on IRC from jbonofre. For future
posterity, the solution was to

1) add the framework to the verify :

org.apache.karaf.features:framework

  framework


2) add the framework feature as a descriptor

3) ensure the org.apache.karaf.features.framework kar artifact 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/test-karaf-verify
> 
> Just run "mvn install" to see the issue.
> 
> Then, at
> https://github.com/rocketraman/test-karaf-verify/blob/master/dist/pom.xml#L41
> comment out the feature-with-slf4j and uncomment feature-without-slf4j
> to see that verification succeeds when slf4j is not a dependency.
> 
> Regards,
> Raman
> 
> 
> On 01/28/2016 10:31 AM, Jean-Baptiste Onofré wrote:
>> Hi Raman,
>>
>> Can you share both your pom.xml (as you already did) and your
>> features.xml ?
>> I gonna fix that for you.
>>
>> Thanks,
>> 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
>>> features that use wrap, and created the simplest possible features to
>>> test. I see that:
>>>
>>> - if a feature contains a bundle that declares an import of
>>> org.slf4j;version="[1.7,2)" then the verification fails with the error:
>>>
>>> missing requirement [my-bundle/1.0.0.SNAPSHOT] osgi.wiring.package;
>>> filter:="(&(osgi.wiring.package=org.slf4j)(version>=1.7.0)(!(version>=2.0.0)))"]
>>>
>>>
>>> - if a feature contains a bundle that does not declare an import on
>>> org.slf4j, then the verification succeeds
>>>
>>> So, for some reason, perhaps the verification framework isn't loading
>>> the logging bundle?
>>>
>>> Interestingly, I tried adding >> prerequisite="true">log to the feature under verification,
>>> but it just pushed the problem back by one system bundle. Instead of
>>> the error above, I got:
>>>
>>> missing requirement [org.apache.karaf.log.core/4.0.4]
>>> osgi.wiring.package;
>>> filter:="(&(osgi.wiring.package=org.ops4j.pax.logging.spi)(version>=1.8.0)(!(version>=2.0.0)))"]
>>>
>>>
>>> Thoughts?
>>>
>>> Regards,
>>> Raman
>>>
>>> On 01/28/2016 08:25 AM, Jean-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 dependency="true".
>>>>
>>>> Regards
>>>> JB
>>>>
>>>> On 01/28/2016 02:18 PM, Raman Gupta wrote:
>>>>> 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 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 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  section as
>>>>>>>> well as
>>>>>>>> the plugin .
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Raman
>>>>>>>>
>>>>>>>> On 01/26/2016 12:24 PM, Jean-Bap

Re: Karaf insisting on loading older version of feature?

[Raman Gupta]

I just tried it again on a totally vanilla karaf instance, newly
decompressed from the tar.gz:

feature:install spring-dm-web

results in both Spring 3.1.4 and Spring 3.2.14 being loaded:

karaf@root()> list -t 0 -l | grep spring
 58 | Active   |  30 | 4.0.4|
mvn:org.apache.karaf.bundle/org.apache.karaf.bundle.springstate/4.0.4
 59 | Active   |  30 | 4.0.4|
mvn:org.apache.karaf.deployer/org.apache.karaf.deployer.spring/4.0.4
 63 | Active   |  30 | 3.2.14.RELEASE_1 |
mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.spring-aop/3.2.14.RELEASE_1
 64 | Active   |  30 | 3.2.14.RELEASE_1 |
mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.spring-beans/3.2.14.RELEASE_1
 65 | Active   |  30 | 3.2.14.RELEASE_1 |
mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.spring-context/3.2.14.RELEASE_1
 66 | Active   |  30 | 3.2.14.RELEASE_1 |
mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.spring-context-support/3.2.14.RELEASE_1
 67 | Active   |  30 | 3.2.14.RELEASE_1 |
mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.spring-core/3.2.14.RELEASE_1
 68 | Active   |  30 | 3.2.14.RELEASE_1 |
mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.spring-expression/3.2.14.RELEASE_1
 69 | Active   |  30 | 3.2.14.RELEASE_1 |
mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.spring-web/3.2.14.RELEASE_1
 70 | Active   |  30 | 3.2.14.RELEASE_1 |
mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.spring-webmvc/3.2.14.RELEASE_1
102 | Active   |  30 | 3.1.4.RELEASE|
mvn:org.springframework/spring-aop/3.1.4.RELEASE
103 | Active   |  30 | 3.1.4.RELEASE|
mvn:org.springframework/spring-asm/3.1.4.RELEASE
104 | Active   |  30 | 3.1.4.RELEASE|
mvn:org.springframework/spring-beans/3.1.4.RELEASE
105 | Active   |  30 | 3.1.4.RELEASE|
mvn:org.springframework/spring-context/3.1.4.RELEASE
106 | Active   |  30 | 3.1.4.RELEASE|
mvn:org.springframework/spring-context-support/3.1.4.RELEASE
107 | Active   |  30 | 3.1.4.RELEASE|
mvn:org.springframework/spring-core/3.1.4.RELEASE
108 | Active   |  30 | 3.1.4.RELEASE|
mvn:org.springframework/spring-expression/3.1.4.RELEASE
109 | Active   |  30 | 1.2.1|
mvn:org.springframework.osgi/spring-osgi-core/1.2.1
110 | Active   |  30 | 1.2.1|
mvn:org.springframework.osgi/spring-osgi-extender/1.2.1
111 | Active   |  30 | 1.2.1|
mvn:org.springframework.osgi/spring-osgi-annotation/1.2.1
112 | Active   |  30 | 1.2.1|
mvn:org.springframework.osgi/spring-osgi-io/1.2.1
113 | Active   |  30 | 1.2.1|
mvn:org.springframework.osgi/spring-osgi-web/1.2.1

Regards,
Raman


On 01/31/2016 08:25 AM, Jean-Baptiste Onofré wrote:
> Hi Christian,
> 
> feature core does not depend to spring.
> 
> I don't think the problem is on feature core: the error message says
> it's the spring (osgi.identity) feature (type) that doesn't resolve
> (and it's normal as 3.1.4 is blacklisted and 3.2 excluded from the
> range).
> 
> @Raman, it works fine for me (for a vanilla Karaf): if I don't
> feature:install spring-dm, I have the 3.2.14 Spring features installed:
> 
> 
> 52 | Active   |  30 | 4.0.4| Apache Karaf :: Bundle ::
> SpringStateService
> 53 | Active   |  30 | 4.0.4| Apache Karaf :: Deployer ::
> Spring
> 54 | Active   |  30 | 1.0.0.6  | Apache ServiceMix :: Bundles
> :: aopalliance
> 55 | Active   |  30 | 3.2.0.1  | Apache ServiceMix :: Bundles
> :: cglib
> 56 | Active   |  30 | 3.2.14.RELEASE_1 | Apache ServiceMix :: Bundles
> :: spring-aop
> 57 | Active   |  30 | 3.2.14.RELEASE_1 | Apache ServiceMix :: Bundles
> :: spring-beans
> 58 | Active   |  30 | 3.2.14.RELEASE_1 | Apache ServiceMix :: Bundles
> :: spring-context
> 59 | Active   |  30 | 3.2.14.RELEASE_1 | Apache ServiceMix :: Bundles
> :: spring-context-support
> 60 | Active   |  30 | 3.2.14.RELEASE_1 | Apache ServiceMix :: Bundles
> :: spring-core
> 61 | Active   |  30 | 3.2.14.RELEASE_1 | Apache ServiceMix :: Bundles
> :: spring-expression
> 
> and:
> 
> spring-dm   | 1.2.1| x| Started | spring-4.0.4
>  | Spring DM support
> spring  | 3.2.14.RELEASE_1 |  | Started | spring-4.0.4
>  | Spring 3.2.x support
> 
> IMHO, you have another feature installed (or transitively installed)
> 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 the spring release to <3.2.0. So the resolver can not choose a
>> higher version.
>>
>> Christian
>>
>>
>> 2016-01-31 2:29 GMT+01:00 Raman Gupta <rocketra...@gmail.com
>>

Re: Karaf insisting on loading older version of feature?

[Raman Gupta]

Here is another odd thing: if you `feature:install http` *first* all
the pax-web bundles (as well as jetty and so on) load, with no Spring
dependencies. If you *then* feature:install spring-dm-web, it loads
*without* installing the Spring 3.1.4 bundles.

In addition, I was able to copy the spring-dm-web feature into my own
features repo, with the only modification being a minimum range of 3.2
for Spring, and loading that feature works fine as well -- it does not
load the Spring 3.1.4 bundles. So it isn't a simple transitive
dependency issue.

Regards,
Raman

On Mon, Feb 1, 2016 at 10:35 AM, Jean-Baptiste Onofré <j...@nanthrax.net> wrote:
> I just installed the spring-dm feature, so the spring-dm-web probably
> installs transitively another feature requiring spring 3.1 (but not 3.2).
>
> With feature:install -v shows that spring 3.1 is installed just after
> pax-web 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 spring-dm-web
>>
>> results in both Spring 3.1.4 and Spring 3.2.14 being loaded:
>>
>> karaf@root()> list -t 0 -l | grep spring
>>   58 | Active   |  30 | 4.0.4|
>> mvn:org.apache.karaf.bundle/org.apache.karaf.bundle.springstate/4.0.4
>>   59 | Active   |  30 | 4.0.4|
>> mvn:org.apache.karaf.deployer/org.apache.karaf.deployer.spring/4.0.4
>>   63 | Active   |  30 | 3.2.14.RELEASE_1 |
>>
>> mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.spring-aop/3.2.14.RELEASE_1
>>   64 | Active   |  30 | 3.2.14.RELEASE_1 |
>>
>> mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.spring-beans/3.2.14.RELEASE_1
>>   65 | Active   |  30 | 3.2.14.RELEASE_1 |
>>
>> mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.spring-context/3.2.14.RELEASE_1
>>   66 | Active   |  30 | 3.2.14.RELEASE_1 |
>>
>> mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.spring-context-support/3.2.14.RELEASE_1
>>   67 | Active   |  30 | 3.2.14.RELEASE_1 |
>>
>> mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.spring-core/3.2.14.RELEASE_1
>>   68 | Active   |  30 | 3.2.14.RELEASE_1 |
>>
>> mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.spring-expression/3.2.14.RELEASE_1
>>   69 | Active   |  30 | 3.2.14.RELEASE_1 |
>>
>> mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.spring-web/3.2.14.RELEASE_1
>>   70 | Active   |  30 | 3.2.14.RELEASE_1 |
>>
>> mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.spring-webmvc/3.2.14.RELEASE_1
>> 102 | Active   |  30 | 3.1.4.RELEASE|
>> mvn:org.springframework/spring-aop/3.1.4.RELEASE
>> 103 | Active   |  30 | 3.1.4.RELEASE|
>> mvn:org.springframework/spring-asm/3.1.4.RELEASE
>> 104 | Active   |  30 | 3.1.4.RELEASE|
>> mvn:org.springframework/spring-beans/3.1.4.RELEASE
>> 105 | Active   |  30 | 3.1.4.RELEASE|
>> mvn:org.springframework/spring-context/3.1.4.RELEASE
>> 106 | Active   |  30 | 3.1.4.RELEASE|
>> mvn:org.springframework/spring-context-support/3.1.4.RELEASE
>> 107 | Active   |  30 | 3.1.4.RELEASE|
>> mvn:org.springframework/spring-core/3.1.4.RELEASE
>> 108 | Active   |  30 | 3.1.4.RELEASE|
>> mvn:org.springframework/spring-expression/3.1.4.RELEASE
>> 109 | Active   |  30 | 1.2.1|
>> mvn:org.springframework.osgi/spring-osgi-core/1.2.1
>> 110 | Active   |  30 | 1.2.1|
>> mvn:org.springframework.osgi/spring-osgi-extender/1.2.1
>> 111 | Active   |  30 | 1.2.1|
>> mvn:org.springframework.osgi/spring-osgi-annotation/1.2.1
>> 112 | Active   |  30 | 1.2.1|
>> mvn:org.springframework.osgi/spring-osgi-io/1.2.1
>> 113 | Active   |  30 | 1.2.1|
>> mvn:org.springframework.osgi/spring-osgi-web/1.2.1
>>
>> Regards,
>> Raman
>>
>>
>> On 01/31/2016 08:25 AM, Jean-Baptiste Onofré wrote:
>>>
>>> Hi Christian,
>>>
>>> feature core does not depend to spring.
>>>
>>> I don't think the problem is on feature core: the error message says
>>> it's the spring (osgi.identity) feature (type) that doesn't resolve
>>> (and it's normal as 3.1.4 is blacklisted and 3.2 excluded from the
>>> range).
>>>
>>> @Raman, it works fine for me (for a vanilla Karaf): if I don't
>>> feature:install spring-dm, I have the 3.2.14 Spring features installed:
>>>
>>>
>&g

Karaf insisting on loading older version of feature?

[Raman Gupta]

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 Karaf satisfying the spring-web [2.5.6,4) dependency with
Spring 3.1.4 when Spring 3.2.14.RELEASE_1 is available in the same
features repo?

In addition, blacklisting 3.1.4 does not help -- Karaf still attempts
to resolve the dependency with the same version, and fails:

2016-01-30 19:21:26,192 | ERROR | nsole user karaf | ShellUtil
| 44 - org.apache.karaf.shell.core - 4.0.4 | Exception
caught while executing command
org.osgi.service.resolver.ResolutionException: Unable to resolve root:
missing requirement [root] osgi.identity; osgi.identity=spring;
type=karaf.feature; version="[3.1.4.RELEASE,3.2.0)"

Regards,
Raman

Re: Features validation: cannot find wrap

[Raman Gupta]

Thanks JB, here is a simple test case:

https://github.com/rocketraman/test-karaf-verify

Just run "mvn install" to see the issue.

Then, at
https://github.com/rocketraman/test-karaf-verify/blob/master/dist/pom.xml#L41
comment out the feature-with-slf4j and uncomment feature-without-slf4j
to see that verification succeeds when slf4j is not a dependency.

Regards,
Raman


On 01/28/2016 10:31 AM, Jean-Baptiste Onofré wrote:
> Hi Raman,
> 
> Can you share both your pom.xml (as you already did) and your
> features.xml ?
> I gonna fix that for you.
> 
> Thanks,
> 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
>> features that use wrap, and created the simplest possible features to
>> test. I see that:
>>
>> - if a feature contains a bundle that declares an import of
>> org.slf4j;version="[1.7,2)" then the verification fails with the error:
>>
>> missing requirement [my-bundle/1.0.0.SNAPSHOT] osgi.wiring.package;
>> filter:="(&(osgi.wiring.package=org.slf4j)(version>=1.7.0)(!(version>=2.0.0)))"]
>>
>>
>> - if a feature contains a bundle that does not declare an import on
>> org.slf4j, then the verification succeeds
>>
>> So, for some reason, perhaps the verification framework isn't loading
>> the logging bundle?
>>
>> Interestingly, I tried adding > prerequisite="true">log to the feature under verification,
>> but it just pushed the problem back by one system bundle. Instead of
>> the error above, I got:
>>
>> missing requirement [org.apache.karaf.log.core/4.0.4]
>> osgi.wiring.package;
>> filter:="(&(osgi.wiring.package=org.ops4j.pax.logging.spi)(version>=1.8.0)(!(version>=2.0.0)))"]
>>
>>
>> Thoughts?
>>
>> Regards,
>> Raman
>>
>> On 01/28/2016 08:25 AM, Jean-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 dependency="true".
>>>
>>> Regards
>>> JB
>>>
>>> On 01/28/2016 02:18 PM, Raman Gupta wrote:
>>>> 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 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 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  section as
>>>>>>> well as
>>>>>>> the plugin .
>>>>>>>
>>>>>>> Regards,
>>>>>>> Raman
>>>>>>>
>>>>>>> On 01/26/2016 12:24 PM, Jean-Baptiste Onofré wrote:
>>>>>>>> Hi Raman,
>>>>>>>>
>>>>>>>> Can you check if standard feature dependency is present in the
>>>>>>>> pom.xml
>>>>>>>> and with compile as scope ?
>>>>>>>>
>>>>>>>> Basically, you should have:
>>>>>>>>
>>>>>>>>
>>>>>>>>org.apache.karaf.features
>>>>>>>>framework
>>>>>>>>4.0.4
>>>>>>>>kar
>>>>>>>>
>>>>>>>>
>>>>>>>>org.apache.karaf.features
>>>>>>>>standard
>>>>>>&g

Re: Features validation: cannot find wrap

[Raman Gupta]

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 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 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  section as well as
>>> the plugin .
>>>
>>> Regards,
>>> Raman
>>>
>>> On 01/26/2016 12:24 PM, Jean-Baptiste Onofré wrote:
>>>> Hi Raman,
>>>>
>>>> Can you check if standard feature dependency is present in the pom.xml
>>>> and with compile as scope ?
>>>>
>>>> Basically, you should have:
>>>>
>>>>  
>>>>  org.apache.karaf.features
>>>>  framework
>>>>  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, Raman Gupta wrote:
>>>>> I am trying to use karaf-maven-plugin version 4.0.4 to verify a
>>>>> feature, but always get the following error:
>>>>>
>>>>> Message: Unable to resolve root: missing requirement [root]
>>>>> osgi.identity; osgi.identity=wrap; type=karaf.feature; version=0;
>>>>> filter:="(&(osgi.identity=wrap)(type=karaf.feature)(version>=0.0.0))"
>>>>> [caused by: Unable to resolve wrap/0.0.0: missing requirement
>>>>> [wrap/0.0.0] osgi.identity; osgi.identity=org.ops4j.pax.url.wrap;
>>>>> type=osgi.bundle; version="[2.4.5,2.4.5]"; resolution:=mandatory
>>>>> [caused by: Unable to resolve org.ops4j.pax.url.wrap/2.4.5: missing
>>>>> requirement [org.ops4j.pax.url.wrap/2.4.5] osgi.wiring.package;
>>>>> filter:="(&(osgi.wiring.package=org.slf4j)(version>=1.6.0)(!(version>=2.0.0)))"]]
>>>>>
>>>>>
>>>>>
>>>>> It seems that the pax wrap feature is not being loaded by the
>>>>> verifier
>>>>> (wrap is used in my features.xml).
>>>>>
>>>>> I don't specify a custom config.properties, so the default is being
>>>>> used, which should load the wrap feature.
>>>>>
>>>>> Any ideas?
>>>>>
>>>>> Regards,
>>>>> Raman Gupta
>>>>>
>>>>
>>

Re: Features validation: cannot find wrap

[Raman Gupta]

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
features that use wrap, and created the simplest possible features to
test. I see that:

- if a feature contains a bundle that declares an import of
org.slf4j;version="[1.7,2)" then the verification fails with the error:

missing requirement [my-bundle/1.0.0.SNAPSHOT] osgi.wiring.package;
filter:="(&(osgi.wiring.package=org.slf4j)(version>=1.7.0)(!(version>=2.0.0)))"]

- if a feature contains a bundle that does not declare an import on
org.slf4j, then the verification succeeds

So, for some reason, perhaps the verification framework isn't loading
the logging bundle?

Interestingly, I tried adding log to the feature under verification,
but it just pushed the problem back by one system bundle. Instead of
the error above, I got:

missing requirement [org.apache.karaf.log.core/4.0.4]
osgi.wiring.package;
filter:="(&(osgi.wiring.package=org.ops4j.pax.logging.spi)(version>=1.8.0)(!(version>=2.0.0)))"]

Thoughts?

Regards,
Raman

On 01/28/2016 08:25 AM, Jean-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 dependency="true".
> 
> Regards
> JB
> 
> On 01/28/2016 02:18 PM, Raman Gupta wrote:
>> 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 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 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  section as
>>>>> well as
>>>>> the plugin .
>>>>>
>>>>> Regards,
>>>>> Raman
>>>>>
>>>>> On 01/26/2016 12:24 PM, Jean-Baptiste Onofré wrote:
>>>>>> Hi Raman,
>>>>>>
>>>>>> Can you check if standard feature dependency is present in the
>>>>>> pom.xml
>>>>>> and with compile as scope ?
>>>>>>
>>>>>> Basically, you should have:
>>>>>>
>>>>>>   
>>>>>>   org.apache.karaf.features
>>>>>>   framework
>>>>>>   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, Raman Gupta wrote:
>>>>>>> I am trying to use karaf-maven-plugin version 4.0.4 to verify a
>>>>>>> feature, but always get the following error:
>>>>>>>
>>>>>>> Message: Unable to resolve root: missing requirement [root]
>>>>>>> osgi.identity; osgi.identity=wrap; type=karaf.feature; version=0;
>>>>>>> filter:="(&(osgi.identity=wrap)(type=karaf.feature)(version>=0.0.0))"
>>>>>>>
>>>>>>> [caused by: Unable to resolve wrap/0.0.0: missing requirement
>>>>>>> [wrap/0.0.0] osgi.identity; osgi.identity=org.ops4j.pax.url.wrap;
>>>>>>> type=osgi.bundle; version="[2.4.5,2.4.5]"; resolution:=mandatory
>>>>>>> [caused by: Unable to resolve org.ops4j.pax.url.wrap/2.4.5:
>>>>>>> missing
>>>>>>> requirement [org.ops4j.pax.url.wrap/2.4.5] osgi.wiring.package;
>>>>>>> filter:="(&(osgi.wiring.package=org.slf4j)(version>=1.6.0)(!(version>=2.0.0)))"]]
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> It seems that the pax wrap feature is not being loaded by the
>>>>>>> verifier
>>>>>>> (wrap is used in my features.xml).
>>>>>>>
>>>>>>> I don't specify a custom config.properties, so the default is
>>>>>>> being
>>>>>>> used, which should load the wrap feature.
>>>>>>>
>>>>>>> Any ideas?
>>>>>>>
>>>>>>> Regards,
>>>>>>> Raman Gupta
>>>>>>>
>>>>>>
>>>>
>>
> 

Features validation: cannot find wrap

[Raman Gupta]

I am trying to use karaf-maven-plugin version 4.0.4 to verify a
feature, but always get the following error:

Message: Unable to resolve root: missing requirement [root]
osgi.identity; osgi.identity=wrap; type=karaf.feature; version=0;
filter:="(&(osgi.identity=wrap)(type=karaf.feature)(version>=0.0.0))"
[caused by: Unable to resolve wrap/0.0.0: missing requirement
[wrap/0.0.0] osgi.identity; osgi.identity=org.ops4j.pax.url.wrap;
type=osgi.bundle; version="[2.4.5,2.4.5]"; resolution:=mandatory
[caused by: Unable to resolve org.ops4j.pax.url.wrap/2.4.5: missing
requirement [org.ops4j.pax.url.wrap/2.4.5] osgi.wiring.package;
filter:="(&(osgi.wiring.package=org.slf4j)(version>=1.6.0)(!(version>=2.0.0)))"]]

It seems that the pax wrap feature is not being loaded by the verifier
(wrap is used in my features.xml).

I don't specify a custom config.properties, so the default is being
used, which should load the wrap feature.

Any ideas?

Regards,
Raman Gupta

Re: Features validation: cannot find wrap

[Raman Gupta]

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  section as well as
the plugin .

Regards,
Raman

On 01/26/2016 12:24 PM, Jean-Baptiste Onofré wrote:
> Hi Raman,
> 
> Can you check if standard feature dependency is present in the pom.xml
> and with compile as scope ?
> 
> Basically, you should have:
> 
> 
> org.apache.karaf.features
> framework
> 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, Raman Gupta wrote:
>> I am trying to use karaf-maven-plugin version 4.0.4 to verify a
>> feature, but always get the following error:
>>
>> Message: Unable to resolve root: missing requirement [root]
>> osgi.identity; osgi.identity=wrap; type=karaf.feature; version=0;
>> filter:="(&(osgi.identity=wrap)(type=karaf.feature)(version>=0.0.0))"
>> [caused by: Unable to resolve wrap/0.0.0: missing requirement
>> [wrap/0.0.0] osgi.identity; osgi.identity=org.ops4j.pax.url.wrap;
>> type=osgi.bundle; version="[2.4.5,2.4.5]"; resolution:=mandatory
>> [caused by: Unable to resolve org.ops4j.pax.url.wrap/2.4.5: missing
>> requirement [org.ops4j.pax.url.wrap/2.4.5] osgi.wiring.package;
>> filter:="(&(osgi.wiring.package=org.slf4j)(version>=1.6.0)(!(version>=2.0.0)))"]]
>>
>>
>> It seems that the pax wrap feature is not being loaded by the verifier
>> (wrap is used in my features.xml).
>>
>> I don't specify a custom config.properties, so the default is being
>> used, which should load the wrap feature.
>>
>> Any ideas?
>>
>> Regards,
>> Raman Gupta
>>
> 

Re: Features validation: cannot find wrap

[Raman Gupta]

Some more info:

Originally in my  I add included the Karaf features:

mvn:org.apache.karaf.features/standard/${karaf.version}/xml/features
mvn:org.apache.karaf.features/spring/${karaf.version}/xml/features
mvn:org.apache.karaf.features/enterprise/${karaf.version}/xml/features

Removing those and keeping only my own feature descriptors results in
a different error:

[WARNING] Feature resolution failed for [myfeature/myversion]
Message: Unable to resolve root: missing requirement [root]
osgi.identity; osgi.identity=wrap; type=karaf.feature; version=0;
filter:="(&(osgi.identity=wrap)(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  section as well as
> the plugin .
> 
> Regards,
> Raman
> 
> On 01/26/2016 12:24 PM, Jean-Baptiste Onofré wrote:
>> Hi Raman,
>>
>> Can you check if standard feature dependency is present in the pom.xml
>> and with compile as scope ?
>>
>> Basically, you should have:
>>
>> 
>> org.apache.karaf.features
>> framework
>> 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, Raman Gupta wrote:
>>> I am trying to use karaf-maven-plugin version 4.0.4 to verify a
>>> feature, but always get the following error:
>>>
>>> Message: Unable to resolve root: missing requirement [root]
>>> osgi.identity; osgi.identity=wrap; type=karaf.feature; version=0;
>>> filter:="(&(osgi.identity=wrap)(type=karaf.feature)(version>=0.0.0))"
>>> [caused by: Unable to resolve wrap/0.0.0: missing requirement
>>> [wrap/0.0.0] osgi.identity; osgi.identity=org.ops4j.pax.url.wrap;
>>> type=osgi.bundle; version="[2.4.5,2.4.5]"; resolution:=mandatory
>>> [caused by: Unable to resolve org.ops4j.pax.url.wrap/2.4.5: missing
>>> requirement [org.ops4j.pax.url.wrap/2.4.5] osgi.wiring.package;
>>> filter:="(&(osgi.wiring.package=org.slf4j)(version>=1.6.0)(!(version>=2.0.0)))"]]
>>>
>>>
>>> It seems that the pax wrap feature is not being loaded by the verifier
>>> (wrap is used in my features.xml).
>>>
>>> I don't specify a custom config.properties, so the default is being
>>> used, which should load the wrap feature.
>>>
>>> Any ideas?
>>>
>>> Regards,
>>> Raman Gupta
>>>
>>

Re: Features validation: cannot find wrap

[Raman Gupta]

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 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  section as well as
>> the plugin .
>>
>> Regards,
>> Raman
>>
>> On 01/26/2016 12:24 PM, Jean-Baptiste Onofré wrote:
>>> Hi Raman,
>>>
>>> Can you check if standard feature dependency is present in the pom.xml
>>> and with compile as scope ?
>>>
>>> Basically, you should have:
>>>
>>>  
>>>  org.apache.karaf.features
>>>  framework
>>>  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, Raman Gupta wrote:
>>>> I am trying to use karaf-maven-plugin version 4.0.4 to verify a
>>>> feature, but always get the following error:
>>>>
>>>> Message: Unable to resolve root: missing requirement [root]
>>>> osgi.identity; osgi.identity=wrap; type=karaf.feature; version=0;
>>>> filter:="(&(osgi.identity=wrap)(type=karaf.feature)(version>=0.0.0))"
>>>> [caused by: Unable to resolve wrap/0.0.0: missing requirement
>>>> [wrap/0.0.0] osgi.identity; osgi.identity=org.ops4j.pax.url.wrap;
>>>> type=osgi.bundle; version="[2.4.5,2.4.5]"; resolution:=mandatory
>>>> [caused by: Unable to resolve org.ops4j.pax.url.wrap/2.4.5: missing
>>>> requirement [org.ops4j.pax.url.wrap/2.4.5] osgi.wiring.package;
>>>> filter:="(&(osgi.wiring.package=org.slf4j)(version>=1.6.0)(!(version>=2.0.0)))"]]
>>>>
>>>>
>>>>
>>>> It seems that the pax wrap feature is not being loaded by the
>>>> verifier
>>>> (wrap is used in my features.xml).
>>>>
>>>> I don't specify a custom config.properties, so the default is being
>>>> used, which should load the wrap feature.
>>>>
>>>> Any ideas?
>>>>
>>>> Regards,
>>>> Raman Gupta
>>>>
>>>
> 

Re: Features validation: cannot find wrap

[Raman Gupta]

That was already in place. Note that my features.xml works perfectly
fine inside a real Karaf environment. Its just the feature validation
at build time that I can't get working.

Regards,
Raman

On 01/26/2016 03:04 PM, Achim Nierbeck wrote:
> Hi, 
> 
> if one of your own features 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>>:
> 
> 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 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  section as
> well as
> >> the plugin .
> >>
> >> Regards,
> >> Raman
> >>
> >> On 01/26/2016 12:24 PM, Jean-Baptiste Onofré wrote:
> >>> Hi Raman,
> >>>
> >>> Can you check if standard feature dependency is present in the
> pom.xml
> >>> and with compile as scope ?
> >>>
> >>> Basically, you should have:
> >>>
> >>>  
> >>>  org.apache.karaf.features
> >>>  framework
> >>>  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, Raman Gupta wrote:
> >>>> I am trying to use karaf-maven-plugin version 4.0.4 to verify a
> >>>> feature, but always get the following error:
> >>>>
> >>>> Message: Unable to resolve root: missing requirement [root]
> >>>> osgi.identity; osgi.identity=wrap; type=karaf.feature; version=0;
> >>>>
> filter:="(&(osgi.identity=wrap)(type=karaf.feature)(version>=0.0.0))"
> >>>> [caused by: Unable to resolve wrap/0.0.0: missing requirement
> >>>> [wrap/0.0.0] osgi.identity; osgi.identity=org.ops4j.pax.url.wrap;
> >>>> type=osgi.bundle; version="[2.4.5,2.4.5]"; resolution:=mandatory
> >>>> [caused by: Unable to resolve org.ops4j.pax.url.wrap/2.4.5:
> missing
> >>>> requirement [org.ops4j.pax.url.wrap/2.4.5] osgi.wiring.package;
> >>>>
> 
> filter:="(&(osgi.wiring.package=org.slf4j)(version>=1.6.0)(!(version>=2.0.0)))"]]
> >>>>
> >>>>
> >>>>
> >>>> It seems that the pax wrap feature is not being loaded by the
> >>>> verifier
> >>>> (wrap is used in my features.xml).
> >>>>
> >>>> I don't specify a custom config.properties, so the default is
> being
> >>>> used, which should load the wrap feature.
> >>>>
> >>>> Any ideas?
> >>>>
> >>>> Regards,
> >>>> Raman Gupta
> >>>>
> >>>
> >
> 
> 
> 
> 
> -- 
> 
> Apache Member
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
> Committer & Project Lead
> blog <http://notizblog.nierbeck.de/>
> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
> 
> Software Architect / Project Manager / Scrum Master 
> 

Re: dev:restart and permanent generation leak?

[Raman Gupta]

JB, did you have a chance to take a look at this?

Do you want me to create an entry in Jira?

Regards,
Raman


On 01/31/2013 03:05 AM, Jean-Baptiste Onofré wrote:
 Hi Raman,
 
 I tried with Felix, same behavior.
 
 Each dev:restart execution uses around 80% of additional Perm Gen:
 - 23,724,976 - 29,829,568 at first execution
 - 29,829,568 - 35,809,616 at second execution
 ...
 
 I gonna take a look in dev:restart command.
 
 Regards
 JB
 
 On 01/31/2013 08:16 AM, Jean-Baptiste Onofré wrote:
 Hi Raman,

 Users mentioned that with Equinox as well.

 I didn't try with Felix (I will). Not sure 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 Perm Generation
 used = 50648144 (48.30183410644531MB)

 After dev:restart, perm gen size is about 75% bigger:

 $ 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://karaf.922171.n3.nabble.com/dev-restart-and-permanent-generation-leak-tp4027545.html


 Sent from the Karaf - User mailing list archive at Nabble.com.


 

dev:restart and permanent generation leak?

[Raman Gupta]

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 Perm Generation
   used = 50648144 (48.30183410644531MB)

After dev:restart, perm gen size is about 75% bigger:

$ 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://karaf.922171.n3.nabble.com/dev-restart-and-permanent-generation-leak-tp4027545.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Hook into Karaf shutdown process

[Raman Gupta]

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 this with a custom Karaf command that
executes my application shutdown, and then delegates to the Karaf
StopCommand to shutdown Karaf itself.

However, this is not an ideal solution as it requires my custom
command to be explicitly executed. For example, it will not run when a
user does a normal kill or Ctrl-D.

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 look into implementing
this...

Regards,
Raman

Re: Hook into Karaf shutdown process

[Raman Gupta]

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 look into implementing
 this...

I believe I found the right place to do this...

./main/src/main/java/org/apache/karaf/main/Main.java

Just before the call to framework.stop(), we use the BundleContext to
obtain and execute a shutdown method on all services that implement a
new FrameworkShutdownHook interface.

Then, proceed to framework.stop().

Thoughts?

Regards,
Raman Gupta
Principal
VIVO Systems

Re: Spring-DM web and pax web extender bundle processing order in 2.2.7

[Raman Gupta]

On 06/26/2012 07:17 AM, Guillaume Nodet wrote:
 If you use a spring web app, do you really need to use spring-dm in addition ?
 Why don't you just use the spring app ?

I'm not sure what you mean... Spring-DM is what ties in the OSGi
microservices into the web bundle's Spring context, right? How 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 to
 control the extender execution order.
 The reason is that each extender can work synchronously or
 asynchronously and there's no coordination between them, there's not
 even a way to specify such a thing.
 I can only see two ways out:
   * enhance the extenders to better cooperate, but this would require
 enhancing all the extenders and defining some metadata to control such
 an order (given anyone can write an extender, this would be better if
 we had a spec for that)
   * do the synchronization on your own, i.e. you can detect using a
 spring bean when the spring app will be processed and from a servlet
 when the web app stuff will be kicked, then make sure one is waiting
 for the other.

 The last option is the easiest 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.

 I'm trying to do the second option (manual synchronization) as
 described here.

 It isn't working as Pax Web itself attempts to initialize the Spring
 context due to the Spring ContextLoaderListener that is defined in
 web.xml, which then breaks the manual synchronization.

 Here is the stack for the Pax Web initialization of the context:

 http://pastebin.com/raw.php?i=RTunRTkF

 From the stack, the general path to the bean being initialized is:

 swissbox BundleWatcher - WebXmlObserver - WebAppPublisher - Pax Web
 Jetty - ContextLoaderListener - ExtenderOrderingBean.init()

 Then when the servlet is loaded by Pax Web, ExtenderOrderingBean
 thinks the context is good since it was created by Pax Web, and the
 stack which started this whole mess is again produced:

 http://pastebin.com/raw.php?i=PJvMqWRV

 I actually don't see where the Spring-DM extender loads the bean at all...

 So still looking for solutions... IMO, the behavior of Karaf 2.2.4 was
 perfect in this situation, and required no such hackish work-arounds.


Regards,
Raman

Re: Spring-DM web and pax web extender bundle processing order in 2.2.7

[Raman Gupta]

On 06/26/2012 10:56 AM, Guillaume Nodet wrote:
 If you want to use spring-dm and spring-mvc, you want to look at
   http://static.springsource.org/osgi/docs/1.1.0-m2/reference/html/web.html
 There's a special application context class designed for this it seems:
   
 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 a spring web app, do you really need to use spring-dm in 
 addition ?
 Why don't you just use the spring app ?

 I'm not sure what you mean... Spring-DM is what ties in the OSGi
 microservices into the web bundle's Spring context, right? How 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 to
 control the extender execution order.
 The reason is that each extender can work synchronously or
 asynchronously and there's no coordination between them, there's not
 even a way to specify such a thing.
 I can only see two ways out:
   * enhance the extenders to better cooperate, but this would require
 enhancing all the extenders and defining some metadata to control such
 an order (given anyone can write an extender, this would be better if
 we had a spec for that)
   * do the synchronization on your own, i.e. you can detect using a
 spring bean when the spring app will be processed and from a servlet
 when the web app stuff will be kicked, then make sure one is waiting
 for the other.

 The last option is the easiest 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.

 I'm trying to do the second option (manual synchronization) as
 described here.

 It isn't working as Pax Web itself attempts to initialize the Spring
 context due to the Spring ContextLoaderListener that is defined in
 web.xml, which then breaks the manual synchronization.

 Here is the stack for the Pax Web initialization of the context:

 http://pastebin.com/raw.php?i=RTunRTkF

 From the stack, the general path to the bean being initialized is:

 swissbox BundleWatcher - WebXmlObserver - WebAppPublisher - Pax Web
 Jetty - ContextLoaderListener - ExtenderOrderingBean.init()

 Then when the servlet is loaded by Pax Web, ExtenderOrderingBean
 thinks the context is good since it was created by Pax Web, and the
 stack which started this whole mess is again produced:

 http://pastebin.com/raw.php?i=PJvMqWRV

 I actually don't see where the Spring-DM extender loads the bean at all...

 So still looking for solutions... IMO, the behavior of Karaf 2.2.4 was
 perfect in this situation, and required no such hackish work-arounds.


 Regards,
 Raman
 
 
 

Re: Spring-DM web and pax web extender bundle processing order in 2.2.7

[Raman Gupta]

Thanks Guillaume and Achim... I will investigate the manual
synchronization route. Does Pax-web initialize each servlet
synchronously? If so, I can create a dummy servlet that initializes
before the main servlet that can wait for the initialization of the
Spring context.

I also found this post by Peter Krien's responding to a similar query
from someone on the Felix mailing list, and suggesting a similar solution:

http://mail-archives.apache.org/mod_mbox/felix-users/201004.mbox/%3cf5b8b3e9-5602-4caf-9d4f-904fb947b...@aqute.biz%3E

In Krien's solution, rather than manually detecting when a Spring bean
has been initialized, I believe he his suggesting exposes the servlet
itself as a service from the Spring context. When this service is
available, the dummy servlet being initialized by the web extender
sees it and proceeds (I guess this would depend on Pax-Web
processing the dummy servlet first and synchronously).

If that approach works, that would be some functionality that Pax-Web
could use to manage this issue with requiring changes in other
extenders. A manifest header could control whether Pax-Web waits for
some service to be available before proceeding with the servlet
initialization. This would skip the need to manually create the dummy
servlet.

Regards,
Raman


On 06/25/2012 04:12 AM, Achim Nierbeck wrote:
 Hi
 
 I just can second Guillaume here, there is only one more thing that
 crosses my mind.
 Pax Web needs to support Injecting OSGi Services into the Servlets,
 see also [1].
 But as usual this kind of stuff is needed much earlier then implemented :)
 
 regards,
 
 [1] - http://team.ops4j.org/browse/PAXWEB-367
 
 2012/6/25 Guillaume Nodet gno...@gmail.com:
 That's a quite big problem and I'm not really aware of any way to
 control the extender execution order.
 The reason is that each extender can work synchronously or
 asynchronously and there's no coordination between them, there's not
 even a way to specify such a thing.
 I can only see two ways out:
  * enhance the extenders to better cooperate, but this would require
 enhancing all the extenders and defining some metadata to control such
 an order (given anyone can write an extender, this would be better if
 we had a spec for that)
  * do the synchronization on your own, i.e. you can detect using a
 spring bean when the spring app will be processed and from a servlet
 when the web app stuff will be kicked, then make sure one is waiting
 for the other.

 The last option is the easiest 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...@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 to process the bundle *before* the PaxWeb
 extender, since until the app context is created by Spring-DM it is a
 non-functional web bundle. If Pax Web attempts to process it first,
 there is an error about the Spring context not existing when the
 servlet tries to initialize.

 A manual refresh of the bundle is required to fix the problem.

 One difference I can see between 2.2.4 and 2.2.7 is that the start
 level of the pax bundles is different. In Karaf 2.2.4, the pax bundles
 started at the default start level which was 60, but in 2.2.7 the war
 feature specifies they start at the same level as the Spring-DM
 bundles, which is 30. I don't know if that is the underlying problem
 though.

 Is there a way to control the order of the extender execution? If not,
 what is the best work-around?

 Regards,
 Raman



 --
 
 Guillaume Nodet
 
 Blog: http://gnodet.blogspot.com/
 
 FuseSource, Integration everywhere
 http://fusesource.com
 
 
 

Re: Spring-DM web and pax web extender bundle processing order in 2.2.7

[Raman Gupta]

I'm looking at the second solution below (manual synchronization). The
Spring side is easy -- I can create a bean in the context with an
init-method attribute that therefore knows when the Spring context has
been created.

On the servlet side I have created a common servlet called
ExtenderOrderingServlet and set it to load first using the
load-on-startup parameter.

The only place I've found that I can do the wait is in the constructor
of ExtenderOrderingServlet, since the order in which the init() method
is called does not appear to respect the load-on-startup parameter:
init() is called on the other servlets despite the wait in
ExtenderOrderingServlet.

Doing this in the constructor sucks though since I cannot provide any
contextual information to the servlet regarding the name of the
context to wait for, which means I have to create one of these waiter
servlets for *each* web bundle instead of using a common one.

Regards,
Raman


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 to
 control the extender execution order.
 The reason is that each extender can work synchronously or
 asynchronously and there's no coordination between them, there's not
 even a way to specify such a thing.
 I can only see two ways out:
   * enhance the extenders to better cooperate, but this would require
 enhancing all the extenders and defining some metadata to control such
 an order (given anyone can write an extender, this would be better if
 we had a spec for that)
   * do the synchronization on your own, i.e. you can detect using a
 spring bean when the spring app will be processed and from a servlet
 when the web app stuff will be kicked, then make sure one is waiting
 for the other.
 
 The last option is the easiest 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...@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 to process the bundle *before* the PaxWeb
 extender, since until the app context is created by Spring-DM it is a
 non-functional web bundle. If Pax Web attempts to process it first,
 there is an error about the Spring context not existing when the
 servlet tries to initialize.

 A manual refresh of the bundle is required to fix the problem.

 One difference I can see between 2.2.4 and 2.2.7 is that the start
 level of the pax bundles is different. In Karaf 2.2.4, the pax bundles
 started at the default start level which was 60, but in 2.2.7 the war
 feature specifies they start at the same level as the Spring-DM
 bundles, which is 30. I don't know if that is the underlying problem
 though.

 Is there a way to control the order of the extender execution? If not,
 what is the best work-around?

 Regards,
 Raman
 
 
 

Spring-DM web and pax web extender bundle processing order in 2.2.7

[Raman Gupta]

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
non-functional web bundle. If Pax Web attempts to process it first,
there is an error about the Spring context not existing when the
servlet tries to initialize.

A manual refresh of the bundle is required to fix the problem.

One difference I can see between 2.2.4 and 2.2.7 is that the start
level of the pax bundles is different. In Karaf 2.2.4, the pax bundles
started at the default start level which was 60, but in 2.2.7 the war
feature specifies they start at the same level as the Spring-DM
bundles, which is 30. I don't know if that is the underlying problem
though.

Is there a way to control the order of the extender execution? If not,
what is the best work-around?

Regards,
Raman

Re: Install refresh issue

[Raman Gupta]

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 basic bundles but are pretty
limited for advanced use-cases.

For now, Spring-DM 1.2, which works out of the box on Karaf via the
feature, seems to have pretty much all the capabilities of
Gemini-Blueprint, but obviously this will become less and less true as
time goes on.

Regards,
Raman


On 06/12/2012 04:40 PM, Romain Gilles wrote:
 Hi all,
 I'm really interesting too! I have try last week to make Spring
 3.1.1 and Gemini-blueprint works on karaf. I finally succeeded but
 with a patch on gemini and now I trying to work with the gemeni team
 to see if they accept my patch. So if you think that blueprint from
 aries is better let me know. I think blueprint from aries is not
 able to mix standard spring + blueprint as gemini does.
 I think if you have a strong adherence with spring then you will
 have to go on gemini-blueprint as I does. I my case it is not me but
 a third party that use massively spring features.
 Any way if I have time I will try to replace aries blueprint by
 gemini-blueprint. I'm not sure that is possible?

 Romain.

 2012/6/12 bobshort jer...@check-it.ca mailto:jer...@check-it.ca

 I added the Spring feature dependency to my feature and it refreshes
 everything on install. Thanks for the tip!

 On a slightly different topic, I'm curious about the Aries
 usually works
 better than Spring DM comment? We are pretty heavy Spring
 users. I've
 considered switching to Blueprint but haven't seen anything
 definitive on
 what makes it better. There is a lot of Spring specific logic in
 our app I'd
 have to replace, particularly the use of annotations and some aop
 functionality, but I'd consider it if there was a significant
 benefit.

 Can you elaborate on the what makes Aries better?

 --
 View this message in context:
 
 http://karaf.922171.n3.nabble.com/Install-refresh-issue-tp4024804p4024817.html
 Sent from the Karaf - User mailing list archive at Nabble.com.

Re: Bundles built with JDK 7?

[Raman Gupta]

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 (a) start karaf 2.2.x using jre 7 works; (b) compiling your
 bundles using target lvl jre  7 in the maven compiler plugin and
 running it on karaf 2.2.x using jdk 7 works too. That's what I do at
 my environments. I've not tested if it works in other combinations
 too, but I assume so. Best to simply give it a try and report your
 experiences :-)
 
 Kind regards,
 Andreas
 
 On Wed, Mar 28, 2012 at 17:18, Achim Nierbeck bcanh...@googlemail.com wrote:
 well if you rebuild your service with JDK7 you surely need to
 configure Karaf to also use the required JDK/JRE otherwise it won't
 start at all.
 Though I'm unsure if Karaf 2.2.5 does run with JDK7, afaik only Karaf
 3.0.0 was tested with JDK7.
 Another possibility is to compile your service with jdk7 and target
 run-time set to java 6.

 regards, Achim

 2012/3/28 James Gartner james.gart...@moodys.com:
 Right now I'm using 2.2.5, and basically we want to try to recompile a
 current 1.6 service bundle using JDK 1.7, and then redeploy -- we are not
 currently taking advantage of any of the 1.7 changes at all or special
 packages.
 Just not sure how the 1.7 dependencies would be resolved -- do we just need
 to repoint JAVA_HOME on the Karaf machine to Java 7 JDK (or do we even need
 to do that at all?)

 --
 View this message in context: 
 http://karaf.922171.n3.nabble.com/Bundles-built-with-JDK-7-tp3864379p3864742.html
 Sent from the Karaf - User mailing list archive at Nabble.com.



 --

 Apache Karaf http://karaf.apache.org/ Committer  PMC
 OPS4J Pax Web http://wiki.ops4j.org/display/paxweb/Pax+Web/
 Committer  Project Lead
 blog http://notizblog.nierbeck.de/

Re: Scala protocol for Slang

[Raman Gupta]

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 also other languages for the JVM.  Apart from updating the
POMs, it probably needs a bit more work for get the Scala compiler to
work properly again with the OSGi bundles once we upgrade from Scala
2.8 to 2.9 - we had some work to do there for Scalate as well when we
upgraded.
 
 For now, I managed to get it working for 2.8 (which is not the case for
 the master branch), and I'm currently working on porting to 2.9, though
 I do not expect to have too much the same kind of issues you experienced
 for Scalate / Guggla.

My team has gotten Scalate 1.6.0-SNAPSHOT working on Scala 2.9.1 on
Karaf. See this stackoverflow posting for details and links to the
Scalate patches we created (though our Github pull requests have
essentially been ignored by the Scalate team):

http://stackoverflow.com/questions/8935796/getting-the-scala-compiler-to-work-inside-an-osgi-runtime/9048302#9048302

Regards,
Raman
Principal
VIVO Systems

Re: Custom error-page in web.xml not working

[Raman Gupta]

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
 
 there is an issue for this at pax-web
 
 https://team.ops4j.org/browse/PAXWEB-341
 
 but this is about a second wab registering a custom error page.
 
 
 regards, Achim
 
 Am 07.03.2012 19:08, schrieb dleblanc:
 Hello, has there been any progress on this issue? We're seeing the
 same thing
 in our deployment. Is there a Jira we could follow for this? (I
 didn't see
 one).

 Thanks,

   -Dave

 -- 
 View this message in context:
 http://karaf.922171.n3.nabble.com/Custom-error-page-in-web-xml-not-working-tp3607253p3807464.html

 Sent from the Karaf - User mailing list archive at Nabble.com.
 
 

dev:watch and refresh

[Raman Gupta]

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

Re: dev:watch and refresh

[Raman Gupta]

I mean the equivalent of refresh bundle-id at the command line
i.e. OSGi re-resolving the package wiring.

AFAICT, dev:watch is doing the equivalent of update bundle-id, not
update bundle-id; refresh bundle-id.

Regards,
Raman


On 01/12/2012 06:21 PM, Łukasz Dywicki wrote:
 The dev:watch command 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:
 
 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
 

Karaf and aspectj load-time-weaving

[Raman Gupta]

I'd like to have container-level LTW enabled for my bundles. Virgo has
this out of the box using Equinox Aspects and the Equinox aspectj hook.

Karaf uses Felix by default so I was trying to get this working on
Felix, but have not found any solution. So, two questions:

1) Is there a working 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

Re: Aries and Spring Co-Existance in Karaf

[Raman Gupta]

On 11/01/2011 06:05 AM, Ioannis Canellos wrote:
 Let's not confuse blueprint with spring. Blueprint is
 a declarative way to work with OSGi services and Spring is a framework
 for creating applications.
 I don't think that Aries has the same focus with Spring but with SpringDM.
 
 You can always use both, if you have to go with Spring. 
 
 If I had to use Spring, I would use it only where its necessary and
 for managing services etc I would use Aries.
 Example:
 In Cellar 90% of the modules use Aries, but there is a single module
 that uses Spring/SpringDM. We don't have any problem with that.

What would have been nice is if Blueprint provided a way, out of the
box, to expose beans created by Spring or Guice to the Blueprint
context. That way, one could use the DI framework of choice /
annotations inside a bundle, while consistently using Blueprint as a
microservice layer. I'm 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

Re: Aries and Spring Co-Existance in Karaf

[Raman Gupta]

My point wasn't the technology across bundles -- rather, I'm talking
about interop with the DI framework used *within* a bundle.

For example, I may want to use Guice for DI within my bundle, but use
Blueprint to expose/consume OSGi services. As it stands, developers
have to learn each DI framework's own mechanisms for
exposing/consuming services, which means additional complexity,
potential compatibility issues (e.g. Spring proxies), and differing
maturity of implementation (for example, if my DI framework of choice
is Guice, I'm stuck with an immature Peaberry micro-services
implementation).

-- 
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
 mailto:rocketra...@gmail.com wrote:
 
 On 11/01/2011 06:05 AM, Ioannis Canellos wrote:
  Let's not confuse blueprint with spring. Blueprint is
  a declarative way to work with OSGi services and Spring is a
 framework
  for creating applications.
  I don't think that Aries has the same focus with Spring but with
 SpringDM.
 
  You can always use both, if you have to go with Spring.
 
  If I had to use Spring, I would use it only where its necessary and
  for managing services etc I would use Aries.
  Example:
  In Cellar 90% of the modules use Aries, but there is a single module
  that uses Spring/SpringDM. We don't have any problem with that.
 
 What would have been nice is if Blueprint provided a way, out of the
 box, to expose beans created by Spring or Guice to the Blueprint
 context. That way, one could use the DI framework of choice /
 annotations inside a bundle, while consistently using Blueprint as a
 microservice layer. I'm 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

Re: Aries and Spring Co-Existance in Karaf

[Raman Gupta]

 In this example, how would the three contexts work together?  In my work, 
 I've seen coding like this where Spring is desired, and where Aries blueprint 
 doesn't provide the functionality Spring provides.  In that environment, 
 there is a movement towards Eclipse Gemini because it is written to play 
 nicely with Spring.  What I'd like to do is once and for all, identify if 
 Aries and Spring can work in the same bundle or not.  Normally what I hear is 
 no, but from my prototyping, that response doesn't hold water.  

I believe Eclipse Gemini (AKA Spring DM 2.x) *can* mix and match
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

Re: Aries and Spring Co-Existance in Karaf

[Raman Gupta]

On 11/01/2011 10:27 AM, Johan Edstrom wrote:
 I think you are reading this wrong.
 
 Table 5.1. XML Configuration Differences

No. Scroll down to the end of that section.

As mentioned before, in Spring DM one can mix and match the namespaces:

[...snip...]

The example above, uses the Spring 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

Re: Aries and Spring Co-Existance in Karaf

[Raman Gupta]

On 11/01/2011 10:30 AM, mikevan wrote:
 Why can't Gemini work in Karaf?

You're right. I don't know if it will work. I should have said it
doesn't work out of the box. If you decide to try it and get it
working I'd be interested in your features.xml.

I too have used Virgo extensively but have 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://vivosys.com

camel-spring fails to install on Karaf 2.2.4

[Raman Gupta]

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 camel-example-osgi

results in:

Error executing command: Could not start bundle
mvn:org.apache.camel/camel-spring/2.8.1 in feature(s)
camel-spring-2.8.1: Unable to resolve module
org.apache.camel.camel-spring [200.0] because it is exposed to package
'org.springframework.core' from org.springframework.core [79.0] and
org.springframework.core [93.0] via two dependency chains.






Chain 1:



  org.apache.camel.camel-spring [200.0]



import:
((package=org.springframework.core)(version=3.0.0)(!(version=4.0.0)))



 |



export: package=org.springframework.core



  org.springframework.core [79.0]







Chain 2:



  org.apache.camel.camel-spring [200.0]



import:
((package=org.apache.camel.view)(version=2.8.1)(!(version=2.8.2)))



 |



export: package=org.apache.camel.view;
uses:=org.springframework.jmx.export.annotation


  org.apache.camel.camel-core [191.0]



import:
((package=org.springframework.jmx.export.annotation)(version=3.0.0)(!(version=4.0.0)))



 |



export: package=org.springframework.jmx.export.annotation;
uses:=org.springframework.aop.target


  org.springframework.context [98.0]



import:
((package=org.springframework.aop.target)(version=3.0.6)(!(version=3.0.7)))



 |



export: package=org.springframework.aop.target;
uses:=org.springframework.core


  org.springframework.aop [97.0]



import:
((package=org.springframework.core)(version=3.0.6)(!(version=3.0.7)))



 |



export: package=org.springframework.core



  org.springframework.core [93.0]

Re: camel-spring fails to install on Karaf 2.2.4

[Raman Gupta]

Confirmed, using the following feature URL worked:

features:addurl
mvn:org.apache.camel/camel-example-osgi/2.8.2-SNAPSHOT/xml/features

Thanks for your quick reply.

Cheers,
Raman

On 10/20/2011 12:36 AM, j...@nanthrax.net wrote:
 Hi,
 
 It should work with Camel  2.8.2 (release in vote).
 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 to install on Karaf 2.2.4
 Date: Thu, Oct 20, 2011 1:06 am
 
 
 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 camel-example-osgi
 
 results in:
 
 Error executing command: Could not start bundle
 mvn:org.apache.camel/camel-spring/2.8.1 in feature(s)
 camel-spring-2.8.1: Unable to resolve module
 org.apache.camel.camel-spring [200.0] because it is exposed to package
 'org.springframework.core' from org.springframework.core [79.0] and
 org.springframework.core [93.0] via two dependency chains.
 
 
 
 
 
 
 Chain 1:
 
 
 
  org.apache.camel.camel-spring [200.0]
 
 
 
import:
 ((package=org.springframework.core)(version=3.0.0)(!(version=4.0.0)))
 
 
 
 |
 
 
 
export: package=org.springframework.core
 
 
 
  org.springframework.core [79.0]
 
 
 
 
 
 
 
 Chain 2:
 
 
 
  org.apache.camel.camel-spring [200.0]
 
 
 
import:
 ((package=org.apache.camel.view)(version=2.8.1)(!(version=2.8.2)))
 
 
 
 |
 
 
 
export: package=org.apache.camel.view;
 uses:=org.springframework.jmx.export.annotation
 
 
  org.apache.camel.camel-core [191.0]
 
 
 
import:
 ((package=org.springframework.jmx.export.annotation)(version=3.0.0)(!(version=4.0.0)))
 
 
 
 |
 
 
 
export: package=org.springframework.jmx.export.annotation;
 uses:=org.springframework.aop.target
 
 
  org.springframework.context [98.0]
 
 
 
import:
 ((package=org.springframework.aop.target)(version=3.0.6)(!(version=3.0.7)))
 
 
 
 |
 
 
 
export: package=org.springframework.aop.target;
 uses:=org.springframework.core
 
 
  org.springframework.aop [97.0]
 
 
 
import:
 ((package=org.springframework.core)(version=3.0.6)(!(version=3.0.7)))
 
 
 
 |
 
 
 
export: package=org.springframework.core
 
 
 
  org.springframework.core [93.0]