Nabble - Apache Felix - Users

Re: Maven-Bundle-Plugin ignores servicefactory-directive

2009-11-12T13:39:40Z

Mustafa Caylak wrote:

>
>> This is no Customer Service, so you'll have to do some homework.
>> Read [1], slide 18 and following, read [2], slide 19 for an example
>> of annotated class.
>>
>> [1]: http://www.slideshare.net/cziegeler/maven-scr-plugin
>> [2]: http://www.slideshare.net/bdelacretaz/tales-from-the-osgi-trenches
> Yes, you're right. And I hate that I have to ask you guys for help.
> Just a minute ago I argued with someone because he didn't want to do
> his homework.
> I really searched for tutorials or something alike but I couldn't find
> anything.
>
> The two sites you send me - I've never seen them before.
>
> Where I do get these sites?

Here:
http://tinyurl.com/y9vjg53

:)

Guido

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

Re: Maven-Bundle-Plugin ignores servicefactory-directive

2009-11-12T13:34:08Z

> This is no Customer Service, so you'll have to do some homework.
> Read [1], slide 18 and following, read [2], slide 19 for an example of
> annotated class.
>
> [1]: http://www.slideshare.net/cziegeler/maven-scr-plugin
> [2]: http://www.slideshare.net/bdelacretaz/tales-from-the-osgi-trenches
Yes, you're right. And I hate that I have to ask you guys for help. Just
a minute ago I argued with someone because he didn't want to do his
homework.
I really searched for tutorials or something alike but I couldn't find
anything.

The two sites you send me - I've never seen them before.

Where I do get these sites?

I think it won't take any longer until I let you alone :)

Best regards
Mustafa

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

Re: Maven-Bundle-Plugin ignores servicefactory-directive

2009-11-12T13:20:17Z

Mustafa Caylak wrote:

> Hi,
>
> I know that I can set the name of the xml-file. I was just too lazy :)
>
> The problem could be that there is no a directory like
> /target/scr-plugin-generated/OSGI-INF.
> Does it mean that no descriptor.xml is generated?
>
> I'm a bit confused. Where do I use the annotations? Aren't they the
> same annotations that you use when you define a Declarative Service
> Component?
> Where do the scr-plugin know what it has to generate?

You embed JAVA annotations in your Component implementation source code.
When you execute Maven, the scr plugin will inspect the annotated
classes and generate
the corresponding XML Component Descriptor file for you.
>
> I know I'm annoying but you have to bear it, please ^^
This is no Customer Service, so you'll have to do some homework.
Read [1], slide 18 and following, read [2], slide 19 for an example of
annotated class.

[1]: http://www.slideshare.net/cziegeler/maven-scr-plugin
[2]: http://www.slideshare.net/bdelacretaz/tales-from-the-osgi-trenches

Best,
Guido

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

Re: Maven-Bundle-Plugin ignores servicefactory-directive

2009-11-12T12:55:43Z

Hi,

I know that I can set the name of the xml-file. I was just too lazy :)

The problem could be that there is no a directory like
/target/scr-plugin-generated/OSGI-INF.
Does it mean that no descriptor.xml is generated?

I'm a bit confuesed. Where do I use the annotations? Aren't they the
same annotations that you use when you define a Declarative Service
Component?
Where do the scr-plugin know what it has to generate?

I know I'm annoying but you have to bear it, please ^^

I think I hate maven more every day... :P

Regards
Mustafa

Guido Spadotto wrote:

> Mustafa Caylak wrote:
>> Hello Guido,
>>
>> I've used your suggestion, but the only output I got is:
>> [ERROR] Error building bundle
>> de.offis.utils.configSC:configSC:bundle:1.0-SNAPSHOT :
>> Service-Component entry can not be located in JAR: OSGI-INF/Locator.xml
>>
>> Of course I renamed my xml-file to Locator.xml.
>> What do your Locator.xml look like?
>>
> Hi Mustafa,
> first, you can name the *automatically* generated component descriptor
> as you like.
>
> I've named it Locator.xml because that made sense for the component I
> developed,
> but you can set the value of the *component.descriptor.name *property
> to anything
> you like.
>
> That said, could you take a look inside the
> \target\scr-plugin-generated\OSGI-INF
> directory of your project? It should contain the generated component
> descriptor file,
> whose name will be the value of the *component.descriptor.name
> *property, if specified.
>
> If it's there, then the scr plugin worked, and that's all it's
> supposed to do (according to [1]).
>
> In order for the maven-bundle-plugin to insert that descriptor file in
> the bundle,
> you will have to add this directive within its configuration
> instructions:
> <Service-Component>OSGI-INF/${component.descriptor.name}</Service-Component>
>
>
>
> Sorry to ask this, but have you added the relevant annotations inside
> the component implementation?
>
> It might also be that you've experienced [2], but I can't say for sure
> with the amount
> of information you provided so far.
>
> Cheers,
> Guido
>
> [1]: http://felix.apache.org/site/apache-felix-maven-scr-plugin.html
> [2]:
> http://old.nabble.com/-jira--Created:-%28FELIX-1847%29-Error-with-duplicates-when-using-maven-bundle-plugin-2.0.1-and-maven-scr-plugin-1.4-td26216540.html
>
>>
>>
>>
>> Guido Spadotto wrote:
>>> Why don't you just use the maven-scr-plugin and its annotations?
>>> I've found it very handy to generate the component descriptor.
>>>
>>> This is a snippet of a pom of mine (notice there's no bnd file
>>> "tampering"):
>>>
>>> <project xmlns="http://maven.apache.org/POM/4.0.0"
>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
>>> http://maven.apache.org/maven-v4_0_0.xsd">
>>> <modelVersion>4.0.0</modelVersion>
>>> <properties>
>>>
>>> <*component.descriptor.name*>_WhateverYouLike.xml_</component.descriptor.name>
>>> </properties>
>>>
>>> </dependencies>
>>> <build>
>>> <plugins>
>>> <plugin>
>>> <groupId>org.apache.felix</groupId>
>>> <artifactId>maven-bundle-plugin</artifactId>
>>> <extensions>true</extensions>
>>> <configuration>
>>> <instructions>
>>> <Bundle-Name>${project.name}</Bundle-Name>
>>>
>>> <Export-Package>org.something.api</Export-Package>
>>>
>>> <Service-Component>OSGI-INF/${*component.descriptor.name*}</Service-Component>
>>> </instructions>
>>> </configuration>
>>> </plugin>
>>> <plugin>
>>> <groupId>org.apache.felix</groupId>
>>> <artifactId>maven-scr-plugin</artifactId>
>>> <version>1.0.8</version>
>>> <configuration>
>>>
>>> <finalName>${*component.descriptor.name*}</finalName>
>>> </configuration>
>>> <executions>
>>> <execution>
>>> <id>generate-scr-scrdescriptor</id>
>>> <goals>
>>> <goal>scr</goal>
>>> </goals>
>>> </execution>
>>> </executions>
>>> </plugin>
>>> </plugins>
>>> </build>
>>>
>>> </project>
>>>
>>>
>>> Cheers,
>>> Guido
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

Re: Maven-Bundle-Plugin ignores servicefactory-directive

2009-11-12T12:22:53Z

Mustafa Caylak wrote:

> Hello Guido,
>
> I've used your suggestion, but the only output I got is:
> [ERROR] Error building bundle
> de.offis.utils.configSC:configSC:bundle:1.0-SNAPSHOT :
> Service-Component entry can not be located in JAR: OSGI-INF/Locator.xml
>
> Of course I renamed my xml-file to Locator.xml.
> What do your Locator.xml look like?
>

Hi Mustafa,
first, you can name the *automatically* generated component descriptor
as you like.

I've named it Locator.xml because that made sense for the component I
developed,
but you can set the value of the *component.descriptor.name *property to
anything
you like.

That said, could you take a look inside the
\target\scr-plugin-generated\OSGI-INF
directory of your project? It should contain the generated component
descriptor file,
whose name will be the value of the *component.descriptor.name
*property, if specified.

If it's there, then the scr plugin worked, and that's all it's supposed
to do (according to [1]).

In order for the maven-bundle-plugin to insert that descriptor file in
the bundle,
you will have to add this directive within its configuration instructions:
<Service-Component>OSGI-INF/${component.descriptor.name}</Service-Component>

Sorry to ask this, but have you added the relevant annotations inside
the component implementation?

It might also be that you've experienced [2], but I can't say for sure
with the amount
of information you provided so far.

Cheers,
Guido

[1]: http://felix.apache.org/site/apache-felix-maven-scr-plugin.html
[2]:
http://old.nabble.com/-jira--Created:-%28FELIX-1847%29-Error-with-duplicates-when-using-maven-bundle-plugin-2.0.1-and-maven-scr-plugin-1.4-td26216540.html

>
>
>
> Guido Spadotto wrote:
>> Why don't you just use the maven-scr-plugin and its annotations?
>> I've found it very handy to generate the component descriptor.
>>
>> This is a snippet of a pom of mine (notice there's no bnd file
>> "tampering"):
>>
>> <project xmlns="http://maven.apache.org/POM/4.0.0"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
>> http://maven.apache.org/maven-v4_0_0.xsd">
>> <modelVersion>4.0.0</modelVersion>
>> <properties>
>>
>> <*component.descriptor.name*>_WhateverYouLike.xml_</component.descriptor.name>
>> </properties>
>>
>>
>> </dependencies>
>> <build>
>> <plugins>
>> <plugin>
>> <groupId>org.apache.felix</groupId>
>> <artifactId>maven-bundle-plugin</artifactId>
>> <extensions>true</extensions>
>> <configuration>
>> <instructions>
>> <Bundle-Name>${project.name}</Bundle-Name>
>>
>> <Export-Package>org.something.api</Export-Package>
>>
>> <Service-Component>OSGI-INF/${*component.descriptor.name*}</Service-Component>
>> </instructions>
>> </configuration>
>> </plugin>
>> <plugin>
>> <groupId>org.apache.felix</groupId>
>> <artifactId>maven-scr-plugin</artifactId>
>> <version>1.0.8</version>
>> <configuration>
>> <finalName>${*component.descriptor.name*}</finalName>
>> </configuration>
>> <executions>
>> <execution>
>> <id>generate-scr-scrdescriptor</id>
>> <goals>
>> <goal>scr</goal>
>> </goals>
>> </execution>
>> </executions>
>> </plugin>
>> </plugins>
>> </build>
>>
>> </project>
>>
>>
>> Cheers,
>> Guido
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

Re: Maven-Bundle-Plugin ignores servicefactory-directive

2009-11-12T11:06:00Z

Hello Guido,

I've used your suggestion, but the only output I got is:
[ERROR] Error building bundle
de.offis.utils.configSC:configSC:bundle:1.0-SNAPSHOT : Service-Component
entry can not be located in JAR: OSGI-INF/Locator.xml

Of course I renamed my xml-file to Locator.xml.
What do your Locator.xml look like?

Guido Spadotto wrote:

> Why don't you just use the maven-scr-plugin and its annotations?
> I've found it very handy to generate the component descriptor.
>
> This is a snippet of a pom of mine (notice there's no bnd file
> "tampering"):
>
> <project xmlns="http://maven.apache.org/POM/4.0.0"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd">
> <modelVersion>4.0.0</modelVersion>
> <properties>
>
> <component.descriptor.name>Locator.xml</component.descriptor.name>
> </properties>
>
> 
> <dependencies>
> ...
> <dependency>
> <groupId>org.apache.felix</groupId>
> <artifactId>org.apache.felix.scr.annotations</artifactId>
> <version>0.9.0</version>
> </dependency>
> ...
> </dependencies>
> <build>
> <plugins>
> <plugin>
> <groupId>org.apache.felix</groupId>
> <artifactId>maven-bundle-plugin</artifactId>
> <extensions>true</extensions>
> <configuration>
> <instructions>
> <Bundle-Name>${project.name}</Bundle-Name>
> <Export-Package>org.something.api</Export-Package>
>
> <Service-Component>OSGI-INF/${component.descriptor.name}</Service-Component>
> </instructions>
> </configuration>
> </plugin>
> <plugin>
> <groupId>org.apache.felix</groupId>
> <artifactId>maven-scr-plugin</artifactId>
> <version>1.0.8</version>
> <configuration>
> <finalName>${component.descriptor.name}</finalName>
> </configuration>
> <executions>
> <execution>
> <id>generate-scr-scrdescriptor</id>
> <goals>
> <goal>scr</goal>
> </goals>
> </execution>
> </executions>
> </plugin>
> </plugins>
> </build>
>
> </project>
>
>
> Cheers,
> Guido
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

Re: Bundle.findEntries(...) and Bundle-Classpath

2009-11-12T09:35:49Z

Good point. This may get unsuitable for the user list. I think we could
switch to dev@..., if nobody objects (I've just subscribed).
I'm sure this is not off-topic for that list, especially if maybe
something useful will result for Felix. If you have a better suggestion,
I'm all ears.

On 12.11.2009 15:23:11 lukewpatterson wrote:

>
>
> Jeremias Maerki-2 wrote:
> >
> > Looks like we really have to find one good solution for everyone.
> > Otherwise, everyone will continue to find a solution for themselves...
> >
>
> Agreed. Where is the best place to continue this discussion? I want to
> make sure the discussion is archived and open, but I don't want to clog this
> mailing list. At least the subject line should probably be changed.
>
> Thoughts?
> --
> View this message in context: http://old.nabble.com/Bundle.findEntries%28...%29-and-Bundle-Classpath-tp26287340p26319530.html
> Sent from the Apache Felix - Users mailing list archive at Nabble.com.
>

Jeremias Maerki

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

Re: Bundle.findEntries(...) and Bundle-Classpath

2009-11-12T06:23:10Z

Jeremias Maerki-2 wrote:

Looks like we really have to find one good solution for everyone. Otherwise, everyone will continue to find a solution for themselves...

Agreed. Where is the best place to continue this discussion? I want to make sure the discussion is archived and open, but I don't want to clog this mailing list. At least the subject line should probably be changed.

Thoughts?

Felix bundle repository does not consider bundle relationships

2009-11-12T03:58:49Z

Hi,
I have two bundles, bundle1 and bundle2. Both of them depends on bundle3.

The bundle bundle1 does not specify the version of bundle3, while the bundle2 specifies to need bundle3 with version 1.0.

In my repository, I have two versions of bundle3, version 1.0 and version 2.0.

I put them through to felix obr to resolve. The resolver returned the following result:
bundle1, bundle2, bundle3;version=1.0 and bundle3;version2.0

However, my expectation is that the resolver should just return the following:
bundle1, bundle2, bundle3;version=1.0

It is no reason to pull in two versions of the bundle3

It clearly shows that Felix OBR does NOT consider the bundle relations. It should not pull in two versions of the same bundle.

Please can you let me know whether Felix OBR copes with the scenario I described above.

Thanks
Emily

Re: javax.xml.bind classes (JDK 1.6) - Apache Felix Karaf 1.0.0 - Apache CXF 2.2

2009-11-12T01:21:25Z

The reason is that the system bundle exports (or does not export) the
pacakge, depending if you're on jdk 1.5 or 1.6.
This is configured in the etc/config.properties file, and I would
think the best way would be to simply remove this package from the
list and do not let the system bundle export this package.

On Wed, Nov 11, 2009 at 09:21, Charles Moulliard <cmoulliard@...> wrote:

> I would like to know if we have to export (or not) the javax.xml.bind*
> packages defined in the file config.properties file of Apache Felix
> 2.2 when I would like to use Apache CXF. By default, they are exported
> but I have an unresolved constraint issue when deploying bundles
> required fro CXF 2.2 and especially for the following bundle :
>
> mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.jaxb-impl/2.1.6_1
>
> This bundle requires the packages
> javax.xml.bind;version="2.1",javax.xml.bind.annotation;ver
> sion="2.1",javax.xml.bind.annotation.adapters;version="2.1",javax.xml
> .bind.attachment;version="2.1",javax.xml.bind.helpers;version="2.1"
>
> I see using the command exports that these packages are exported but
> though the version 0.0
>
> Remark : in ServiceMix 4.xxx, they are not exported. In this case,
> which jar file export those required packages ?
>
> Regards,
>
> Charles Moulliard
> Senior Enterprise Architect
> Apache Camel Committer
>
> *****************************
> blog : http://cmoulliard.blogspot.com
> twitter : http://twitter.com/cmoulliard
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

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

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

Re: Launching Felix 2.0

2009-11-12T00:40:54Z

Is it possible that you forgot to remove felix 2.0.0 from the classpath?

regards,

Karl

On Thu, Nov 12, 2009 at 3:01 AM, Nikita Sawant <Nikita.Sawant@...> wrote:

> Hi Richard,
>
> Now I am using Framework 2.0.2, I get this exception:
>
> ERROR: Unable to start system bundle. (java.lang.NoClassDefFoundError:
> org.osgi.vendor.framework property not set)
> java.lang.NoClassDefFoundError: org.osgi.vendor.framework property not set
> at org.osgi.framework.FrameworkUtil$1.run(FrameworkUtil.java:62)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.osgi.framework.FrameworkUtil.<clinit>(FrameworkUtil.java:56)
> at
> org.apache.felix.framework.BundleContextImpl.createFilter(BundleContextImpl.java:102)
>
>
> I saw a discussion elsewhere, where the cause for the above was having the
> osgi.core in the classpath. I have removed osgi.core from my classpath, is
> there any other cause for this error?
>
> I am using maven 2.0.8
>
> Thanks,
> Nikita
>
> Richard S. Hall wrote:
>>
>> On 11/11/09 20:15, Nikita Sawant wrote:
>>>
>>> Thanks for the quick reply.
>>>
>>> Ideally I would like to not install the osgi core api into the framework,
>>> I had to cause the framework was not exporting it.
>>
>> Still, if a bundle requires a version of org.osgi.framework that the
>> framework cannot satisfy, then installing it separately will only cause
>> problems like these.
>>
>>> Using the latest Felix runtime should fix this issue, right?
>>
>> 2.0.2 should work...just download main 2.0.2 from the download page and
>> save it over your felix.jar file.
>>
>> -> richard
>>
>>>
>>> Thanks,
>>> Nikita
>>>
>>> Richard S. Hall wrote:
>>>>
>>>> On 11/11/09 20:00, Nikita Sawant wrote:
>>>>>
>>>>> Hi Richard,
>>>>>
>>>>> I followed the instructions to launch Felix in the link below and am
>>>>> able to launch Felix successfully.
>>>>>
>>>>> Now, I can start and stop the felix instance without any problem. When
>>>>> I install a bundle which has a BundleActivator, which is started by my host
>>>>> application I cannot activate the bundle, due to a ClassCastException:
>>>>>
>>>>> Caused by: java.lang.ClassCastException: test.MyInterceptorActivator
>>>>> at
>>>>> org.apache.felix.framework.Felix.createBundleActivator(Felix.java:3525)
>>>>> at
>>>>> org.apache.felix.framework.Felix.activateBundle(Felix.java:1694)
>>>>>
>>>>>
>>>>> Note that I also have the org.osgi.core bundle installed in the felix
>>>>> runtime ( otherwise the bundle I am trying to activate above gives an
>>>>> unresolved constraint error for the org.osgi.framework package ( version
>>>>> >=1.5 ).
>>>>>
>>>>> There seem to be two different definitions of BundleActivator. How do I
>>>>> resolve this issue?
>>>>
>>>> You should not be installing the OSGi core API into the framework, this
>>>> will generally always be a bad idea.
>>>>
>>>> There was a bug in Framework 2.0.0 that we were not exporting the
>>>> version of the OSGi packages with the correct version...that should fix your
>>>> issue.
>>>>
>>>> However, you might want to make sure your bundle actually requires OSGi
>>>> R4.2 API, because it is best to specify the lowest possible version you
>>>> need.
>>>>
>>>> -> richard
>>>>
>>>>>
>>>>> The osgi core I am using is:
>>>>>
>>>>> org.osgi
>>>>> org.osgi.core
>>>>> 4.2.0
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Nikita
>>>>>
>>>>> Richard S. Hall wrote:
>>>>>>
>>>>>> There is a link to our wiki off the "documents" page of the web
>>>>>> site...the link to the actual document is:
>>>>>>
>>>>>>
>>>>>> http://cwiki.apache.org/confluence/display/FELIX/Apache+Felix+Framework+Launching+and+Embedding
>>>>>>
>>>>>> I am not sure why are static site is not syncing with this
>>>>>> page...anyone else have any ideas?
>>>>>>
>>>>>> -> richard
>>>>>>
>>>>>>
>>>>>> On 10/7/09 21:13, Nikita Sawant wrote:
>>>>>>>
>>>>>>> Hi Richard,
>>>>>>>
>>>>>>> Can you provide me the link to the wiki, I could not find it.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Nikita
>>>>>>>
>>>>>>> Richard S. Hall wrote:
>>>>>>>>
>>>>>>>> For some reason our wiki is not correctly being exported to create
>>>>>>>> our static site, so go directly to the wiki for now since it is up to
>>>>>>>> date...unfortunately, the wiki appears to be down right now for me, so I
>>>>>>>> can't give you the link.
>>>>>>>>
>>>>>>>> -> richard
>>>>>>>>
>>>>>>>>
>>>>>>>> On 10/7/09 0:37, Nikita Sawant wrote:
>>>>>>>>>
>>>>>>>>> Hi Richard,
>>>>>>>>>
>>>>>>>>> Where can I find documentation on launching Felix 2.0, similar to
>>>>>>>>> this
>>>>>>>>> <http://felix.apache.org/site/apache-felix-framework-launching-and-embedding.html#ApacheFelixFrameworkLaunchingandEmbedding-standardlauncher>
>>>>>>>>>
>>>>>>>>> The AutoActivator class has been replaced with AutoProcessor, it is
>>>>>>>>> not clear to me how exactly this class is to be configured and used.
>>>>>>>>>
>>>>>>>>> Any information you provide would help.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Nikita
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>>>>>> For additional commands, e-mail: users-help@...
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>>>>> For additional commands, e-mail: users-help@...
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>>>> For additional commands, e-mail: users-help@...
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>>> For additional commands, e-mail: users-help@...
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>> For additional commands, e-mail: users-help@...
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

--
Karl Pauls
karlpauls@...

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

Re: Bundle.findEntries(...) and Bundle-Classpath

2009-11-11T23:25:57Z

On 11.11.2009 16:37:31 lukewpatterson wrote:

>
>
> Jeremias Maerki-2 wrote:
> >
> > On 10.11.2009 18:26:37 lukewpatterson wrote:
> >>
> >> In my activator, I'm bundletracking looking for /META-INF/services
> >> folders.
> >> I wrap around the service-providing bundles with a custom ClassLoader and
> >> then register them with my API's service factory.
> >>
> >> This approach seems to work fine except when the /META-INF/services are
> >> provided exclusively from the Bundle-ClassPath entries. i.e. doesn't
> >> work
> >> when no /META-INF/services folder on root, but embedded jars on the
> >> Bundle-ClassPath have the folder
> >>
> >> Is Bundle.findEntries(...) [1] supposed to look on the Bundle-Classpath?
> >
> > Are you trying to solve the same problem as I've done lately?
> > See: http://www.jeremias-maerki.ch/development/osgi/jar-services.html
> > Well, I didn't specifically look into the Bundle-Classpath issue in this
> > context. I've turned the META-INF/services carrying JARs into full OSGi
> > bundles.
> >
>
> Yes Jeremias, I think what you've done is very close to what I'm looking
> for. I think the restlet team is doing something kinda like this too [1].

Looks like we really have to find one good solution for everyone.
Otherwise, everyone will continue to find a solution for themselves and
we end up with dozens of extenders which scan lots of bundles. And that
is a performance killer (see below).

> I'm working with other teams which use jar SPI (they are kind enough to make
> their stuff bundles, but don't care about OSGi beyond that point), and I
> want a generic way of loading impls. The dynamism obviously wouldn't be
> there, so I was thinking that the appropriate level of bundle state required
> would merely be INSTALLED.

But doesn't INSTALLED mean that the dependencies are not RESOLVED, yet?
So instantiating plug-ins might actually cause ClassNotFoundExceptions.
Especially for debugging, I find it useful, to stop a bundle and thereby
making the plug-ins in that bundle unavailable. That's why I require
the ACTIVE state to make the plug-ins available.

> I started reading through your code and documentation. I was wondering if
> it handles all the scenarios where a bundle can be updated, installed,
> uninstalled.

That was the intention. But I don't have much long-term experience, yet,
but so far it seems to work just fine.

> I was hoping to accomplish this generic lookup without requiring a special
> manifest header, but I see how that introduces all sorts of complexities for
> the implementation (even with BundleTracker and PackageAdmin).

I've added an option (system property) to work without the manifest
header but I've added the header because I've once done a profiling
session of the service locator (implemented as an extender) found in
ServiceMix4's spec bundles. The results:
http://www.mail-archive.com/users@.../msg09270.html
With the header I can avoid scanning the bundles that don't have any JAR
services. Since JARs have to be made OSGi-compatible anyway, adding
another header shouldn't be any trouble, I think.

> [1] http://n2.nabble.com/OSGi-vs-Service-Provider-patterns-td2478338.html
> and
> http://restlet.tigris.org/source/browse/restlet/trunk/modules/org.restlet/src/org/restlet/engine/internal/Activator.java?view=markup
> and
> --
> View this message in context: http://old.nabble.com/Bundle.findEntries%28...%29-and-Bundle-Classpath-tp26287340p26302990.html
> Sent from the Apache Felix - Users mailing list archive at Nabble.com.
>

Jeremias Maerki

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

Re: Launching Felix 2.0

2009-11-11T18:10:01Z

On 11/11/09 21:01, Nikita Sawant wrote:

I am not sure what's up. Seems odd that it worked with 2.0.0 and not
with 2.0.2...are you sure you did everything the same way?

Try to start it the normal way with "java -jar bin/felix.jar"...

-> richard

>
> I am using maven 2.0.8
>
> Thanks,
> Nikita
>
> Richard S. Hall wrote:
>> On 11/11/09 20:15, Nikita Sawant wrote:
>>> Thanks for the quick reply.
>>>
>>> Ideally I would like to not install the osgi core api into the
>>> framework, I had to cause the framework was not exporting it.
>>
>> Still, if a bundle requires a version of org.osgi.framework that the
>> framework cannot satisfy, then installing it separately will only
>> cause problems like these.
>>
>>> Using the latest Felix runtime should fix this issue, right?
>>
>> 2.0.2 should work...just download main 2.0.2 from the download page
>> and save it over your felix.jar file.
>>
>> -> richard
>>
>>>
>>> Thanks,
>>> Nikita
>>>
>>> Richard S. Hall wrote:
>>>> On 11/11/09 20:00, Nikita Sawant wrote:
>>>>> Hi Richard,
>>>>>
>>>>> I followed the instructions to launch Felix in the link below and
>>>>> am able to launch Felix successfully.
>>>>>
>>>>> Now, I can start and stop the felix instance without any problem.
>>>>> When I install a bundle which has a BundleActivator, which is
>>>>> started by my host application I cannot activate the bundle, due
>>>>> to a ClassCastException:
>>>>>
>>>>> Caused by: java.lang.ClassCastException: test.MyInterceptorActivator
>>>>> at
>>>>> org.apache.felix.framework.Felix.createBundleActivator(Felix.java:3525)
>>>>>
>>>>> at
>>>>> org.apache.felix.framework.Felix.activateBundle(Felix.java:1694)
>>>>>
>>>>>
>>>>> Note that I also have the org.osgi.core bundle installed in the
>>>>> felix runtime ( otherwise the bundle I am trying to activate above
>>>>> gives an unresolved constraint error for the org.osgi.framework
>>>>> package ( version >=1.5 ).
>>>>>
>>>>> There seem to be two different definitions of BundleActivator. How
>>>>> do I resolve this issue?
>>>>
>>>> You should not be installing the OSGi core API into the framework,
>>>> this will generally always be a bad idea.
>>>>
>>>> There was a bug in Framework 2.0.0 that we were not exporting the
>>>> version of the OSGi packages with the correct version...that should
>>>> fix your issue.
>>>>
>>>> However, you might want to make sure your bundle actually requires
>>>> OSGi R4.2 API, because it is best to specify the lowest possible
>>>> version you need.
>>>>
>>>> -> richard
>>>>
>>>>>
>>>>> The osgi core I am using is:
>>>>>
>>>>> org.osgi
>>>>> org.osgi.core
>>>>> 4.2.0
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Nikita
>>>>>
>>>>> Richard S. Hall wrote:
>>>>>> There is a link to our wiki off the "documents" page of the web
>>>>>> site...the link to the actual document is:
>>>>>>
>>>>>>
>>>>>> http://cwiki.apache.org/confluence/display/FELIX/Apache+Felix+Framework+Launching+and+Embedding
>>>>>>
>>>>>>
>>>>>> I am not sure why are static site is not syncing with this
>>>>>> page...anyone else have any ideas?
>>>>>>
>>>>>> -> richard
>>>>>>
>>>>>>
>>>>>> On 10/7/09 21:13, Nikita Sawant wrote:
>>>>>>> Hi Richard,
>>>>>>>
>>>>>>> Can you provide me the link to the wiki, I could not find it.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Nikita
>>>>>>>
>>>>>>> Richard S. Hall wrote:
>>>>>>>> For some reason our wiki is not correctly being exported to
>>>>>>>> create our static site, so go directly to the wiki for now
>>>>>>>> since it is up to date...unfortunately, the wiki appears to be
>>>>>>>> down right now for me, so I can't give you the link.
>>>>>>>>
>>>>>>>> -> richard
>>>>>>>>
>>>>>>>>
>>>>>>>> On 10/7/09 0:37, Nikita Sawant wrote:
>>>>>>>>> Hi Richard,
>>>>>>>>>
>>>>>>>>> Where can I find documentation on launching Felix 2.0, similar
>>>>>>>>> to this
>>>>>>>>> <http://felix.apache.org/site/apache-felix-framework-launching-and-embedding.html#ApacheFelixFrameworkLaunchingandEmbedding-standardlauncher>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The AutoActivator class has been replaced with AutoProcessor,
>>>>>>>>> it is not clear to me how exactly this class is to be
>>>>>>>>> configured and used.
>>>>>>>>>
>>>>>>>>> Any information you provide would help.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Nikita
>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>>>>>> For additional commands, e-mail: users-help@...
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>>>>> For additional commands, e-mail: users-help@...
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>>>> For additional commands, e-mail: users-help@...
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>>> For additional commands, e-mail: users-help@...
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>> For additional commands, e-mail: users-help@...
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

Re: Launching Felix 2.0

2009-11-11T18:01:24Z

Hi Richard,

Now I am using Framework 2.0.2, I get this exception:

ERROR: Unable to start system bundle. (java.lang.NoClassDefFoundError:
org.osgi.vendor.framework property not set)
java.lang.NoClassDefFoundError: org.osgi.vendor.framework property not set
at org.osgi.framework.FrameworkUtil$1.run(FrameworkUtil.java:62)
at java.security.AccessController.doPrivileged(Native Method)
at org.osgi.framework.FrameworkUtil.<clinit>(FrameworkUtil.java:56)
at
org.apache.felix.framework.BundleContextImpl.createFilter(BundleContextImpl.java:102)

I saw a discussion elsewhere, where the cause for the above was having
the osgi.core in the classpath. I have removed osgi.core from my
classpath, is there any other cause for this error?

I am using maven 2.0.8

Thanks,
Nikita

Richard S. Hall wrote:

> On 11/11/09 20:15, Nikita Sawant wrote:
>> Thanks for the quick reply.
>>
>> Ideally I would like to not install the osgi core api into the
>> framework, I had to cause the framework was not exporting it.
>
> Still, if a bundle requires a version of org.osgi.framework that the
> framework cannot satisfy, then installing it separately will only
> cause problems like these.
>
>> Using the latest Felix runtime should fix this issue, right?
>
> 2.0.2 should work...just download main 2.0.2 from the download page
> and save it over your felix.jar file.
>
> -> richard
>
>>
>> Thanks,
>> Nikita
>>
>> Richard S. Hall wrote:
>>> On 11/11/09 20:00, Nikita Sawant wrote:
>>>> Hi Richard,
>>>>
>>>> I followed the instructions to launch Felix in the link below and
>>>> am able to launch Felix successfully.
>>>>
>>>> Now, I can start and stop the felix instance without any problem.
>>>> When I install a bundle which has a BundleActivator, which is
>>>> started by my host application I cannot activate the bundle, due to
>>>> a ClassCastException:
>>>>
>>>> Caused by: java.lang.ClassCastException: test.MyInterceptorActivator
>>>> at
>>>> org.apache.felix.framework.Felix.createBundleActivator(Felix.java:3525)
>>>>
>>>> at
>>>> org.apache.felix.framework.Felix.activateBundle(Felix.java:1694)
>>>>
>>>>
>>>> Note that I also have the org.osgi.core bundle installed in the
>>>> felix runtime ( otherwise the bundle I am trying to activate above
>>>> gives an unresolved constraint error for the org.osgi.framework
>>>> package ( version >=1.5 ).
>>>>
>>>> There seem to be two different definitions of BundleActivator. How
>>>> do I resolve this issue?
>>>
>>> You should not be installing the OSGi core API into the framework,
>>> this will generally always be a bad idea.
>>>
>>> There was a bug in Framework 2.0.0 that we were not exporting the
>>> version of the OSGi packages with the correct version...that should
>>> fix your issue.
>>>
>>> However, you might want to make sure your bundle actually requires
>>> OSGi R4.2 API, because it is best to specify the lowest possible
>>> version you need.
>>>
>>> -> richard
>>>
>>>>
>>>> The osgi core I am using is:
>>>>
>>>> org.osgi
>>>> org.osgi.core
>>>> 4.2.0
>>>>
>>>>
>>>> Thanks,
>>>> Nikita
>>>>
>>>> Richard S. Hall wrote:
>>>>> There is a link to our wiki off the "documents" page of the web
>>>>> site...the link to the actual document is:
>>>>>
>>>>>
>>>>> http://cwiki.apache.org/confluence/display/FELIX/Apache+Felix+Framework+Launching+and+Embedding
>>>>>
>>>>>
>>>>> I am not sure why are static site is not syncing with this
>>>>> page...anyone else have any ideas?
>>>>>
>>>>> -> richard
>>>>>
>>>>>
>>>>> On 10/7/09 21:13, Nikita Sawant wrote:
>>>>>> Hi Richard,
>>>>>>
>>>>>> Can you provide me the link to the wiki, I could not find it.
>>>>>>
>>>>>> Thanks,
>>>>>> Nikita
>>>>>>
>>>>>> Richard S. Hall wrote:
>>>>>>> For some reason our wiki is not correctly being exported to
>>>>>>> create our static site, so go directly to the wiki for now since
>>>>>>> it is up to date...unfortunately, the wiki appears to be down
>>>>>>> right now for me, so I can't give you the link.
>>>>>>>
>>>>>>> -> richard
>>>>>>>
>>>>>>>
>>>>>>> On 10/7/09 0:37, Nikita Sawant wrote:
>>>>>>>> Hi Richard,
>>>>>>>>
>>>>>>>> Where can I find documentation on launching Felix 2.0, similar
>>>>>>>> to this
>>>>>>>> <http://felix.apache.org/site/apache-felix-framework-launching-and-embedding.html#ApacheFelixFrameworkLaunchingandEmbedding-standardlauncher>
>>>>>>>>
>>>>>>>>
>>>>>>>> The AutoActivator class has been replaced with AutoProcessor,
>>>>>>>> it is not clear to me how exactly this class is to be
>>>>>>>> configured and used.
>>>>>>>>
>>>>>>>> Any information you provide would help.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Nikita
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>>>>> For additional commands, e-mail: users-help@...
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>>>> For additional commands, e-mail: users-help@...
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>>> For additional commands, e-mail: users-help@...
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>> For additional commands, e-mail: users-help@...
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

Re: Launching Felix 2.0

2009-11-11T17:22:51Z

On 11/11/09 20:15, Nikita Sawant wrote:
> Thanks for the quick reply.
>
> Ideally I would like to not install the osgi core api into the
> framework, I had to cause the framework was not exporting it.

Still, if a bundle requires a version of org.osgi.framework that the
framework cannot satisfy, then installing it separately will only cause
problems like these.

> Using the latest Felix runtime should fix this issue, right?

2.0.2 should work...just download main 2.0.2 from the download page and
save it over your felix.jar file.

-> richard

>
> Thanks,
> Nikita
>
> Richard S. Hall wrote:
>> On 11/11/09 20:00, Nikita Sawant wrote:
>>> Hi Richard,
>>>
>>> I followed the instructions to launch Felix in the link below and am
>>> able to launch Felix successfully.
>>>
>>> Now, I can start and stop the felix instance without any problem.
>>> When I install a bundle which has a BundleActivator, which is
>>> started by my host application I cannot activate the bundle, due to
>>> a ClassCastException:
>>>
>>> Caused by: java.lang.ClassCastException: test.MyInterceptorActivator
>>> at
>>> org.apache.felix.framework.Felix.createBundleActivator(Felix.java:3525)
>>> at
>>> org.apache.felix.framework.Felix.activateBundle(Felix.java:1694)
>>>
>>>
>>> Note that I also have the org.osgi.core bundle installed in the
>>> felix runtime ( otherwise the bundle I am trying to activate above
>>> gives an unresolved constraint error for the org.osgi.framework
>>> package ( version >=1.5 ).
>>>
>>> There seem to be two different definitions of BundleActivator. How
>>> do I resolve this issue?
>>
>> You should not be installing the OSGi core API into the framework,
>> this will generally always be a bad idea.
>>
>> There was a bug in Framework 2.0.0 that we were not exporting the
>> version of the OSGi packages with the correct version...that should
>> fix your issue.
>>
>> However, you might want to make sure your bundle actually requires
>> OSGi R4.2 API, because it is best to specify the lowest possible
>> version you need.
>>
>> -> richard
>>
>>>
>>> The osgi core I am using is:
>>>
>>> org.osgi
>>> org.osgi.core
>>> 4.2.0
>>>
>>>
>>> Thanks,
>>> Nikita
>>>
>>> Richard S. Hall wrote:
>>>> There is a link to our wiki off the "documents" page of the web
>>>> site...the link to the actual document is:
>>>>
>>>>
>>>> http://cwiki.apache.org/confluence/display/FELIX/Apache+Felix+Framework+Launching+and+Embedding
>>>>
>>>>
>>>> I am not sure why are static site is not syncing with this
>>>> page...anyone else have any ideas?
>>>>
>>>> -> richard
>>>>
>>>>
>>>> On 10/7/09 21:13, Nikita Sawant wrote:
>>>>> Hi Richard,
>>>>>
>>>>> Can you provide me the link to the wiki, I could not find it.
>>>>>
>>>>> Thanks,
>>>>> Nikita
>>>>>
>>>>> Richard S. Hall wrote:
>>>>>> For some reason our wiki is not correctly being exported to
>>>>>> create our static site, so go directly to the wiki for now since
>>>>>> it is up to date...unfortunately, the wiki appears to be down
>>>>>> right now for me, so I can't give you the link.
>>>>>>
>>>>>> -> richard
>>>>>>
>>>>>>
>>>>>> On 10/7/09 0:37, Nikita Sawant wrote:
>>>>>>> Hi Richard,
>>>>>>>
>>>>>>> Where can I find documentation on launching Felix 2.0, similar
>>>>>>> to this
>>>>>>> <http://felix.apache.org/site/apache-felix-framework-launching-and-embedding.html#ApacheFelixFrameworkLaunchingandEmbedding-standardlauncher>
>>>>>>>
>>>>>>>
>>>>>>> The AutoActivator class has been replaced with AutoProcessor, it
>>>>>>> is not clear to me how exactly this class is to be configured
>>>>>>> and used.
>>>>>>>
>>>>>>> Any information you provide would help.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Nikita
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>>>> For additional commands, e-mail: users-help@...
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>>> For additional commands, e-mail: users-help@...
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>> For additional commands, e-mail: users-help@...
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

Re: Launching Felix 2.0

2009-11-11T17:15:42Z

Thanks for the quick reply.

Ideally I would like to not install the osgi core api into the
framework, I had to cause the framework was not exporting it.

Using the latest Felix runtime should fix this issue, right?

Thanks,
Nikita

Richard S. Hall wrote:

> On 11/11/09 20:00, Nikita Sawant wrote:
>> Hi Richard,
>>
>> I followed the instructions to launch Felix in the link below and am
>> able to launch Felix successfully.
>>
>> Now, I can start and stop the felix instance without any problem.
>> When I install a bundle which has a BundleActivator, which is started
>> by my host application I cannot activate the bundle, due to a
>> ClassCastException:
>>
>> Caused by: java.lang.ClassCastException: test.MyInterceptorActivator
>> at
>> org.apache.felix.framework.Felix.createBundleActivator(Felix.java:3525)
>> at
>> org.apache.felix.framework.Felix.activateBundle(Felix.java:1694)
>>
>>
>> Note that I also have the org.osgi.core bundle installed in the felix
>> runtime ( otherwise the bundle I am trying to activate above gives an
>> unresolved constraint error for the org.osgi.framework package (
>> version >=1.5 ).
>>
>> There seem to be two different definitions of BundleActivator. How do
>> I resolve this issue?
>
> You should not be installing the OSGi core API into the framework,
> this will generally always be a bad idea.
>
> There was a bug in Framework 2.0.0 that we were not exporting the
> version of the OSGi packages with the correct version...that should
> fix your issue.
>
> However, you might want to make sure your bundle actually requires
> OSGi R4.2 API, because it is best to specify the lowest possible
> version you need.
>
> -> richard
>
>>
>> The osgi core I am using is:
>>
>> org.osgi
>> org.osgi.core
>> 4.2.0
>>
>>
>> Thanks,
>> Nikita
>>
>> Richard S. Hall wrote:
>>> There is a link to our wiki off the "documents" page of the web
>>> site...the link to the actual document is:
>>>
>>>
>>> http://cwiki.apache.org/confluence/display/FELIX/Apache+Felix+Framework+Launching+and+Embedding
>>>
>>>
>>> I am not sure why are static site is not syncing with this
>>> page...anyone else have any ideas?
>>>
>>> -> richard
>>>
>>>
>>> On 10/7/09 21:13, Nikita Sawant wrote:
>>>> Hi Richard,
>>>>
>>>> Can you provide me the link to the wiki, I could not find it.
>>>>
>>>> Thanks,
>>>> Nikita
>>>>
>>>> Richard S. Hall wrote:
>>>>> For some reason our wiki is not correctly being exported to create
>>>>> our static site, so go directly to the wiki for now since it is up
>>>>> to date...unfortunately, the wiki appears to be down right now for
>>>>> me, so I can't give you the link.
>>>>>
>>>>> -> richard
>>>>>
>>>>>
>>>>> On 10/7/09 0:37, Nikita Sawant wrote:
>>>>>> Hi Richard,
>>>>>>
>>>>>> Where can I find documentation on launching Felix 2.0, similar to
>>>>>> this
>>>>>> <http://felix.apache.org/site/apache-felix-framework-launching-and-embedding.html#ApacheFelixFrameworkLaunchingandEmbedding-standardlauncher>
>>>>>>
>>>>>>
>>>>>> The AutoActivator class has been replaced with AutoProcessor, it
>>>>>> is not clear to me how exactly this class is to be configured and
>>>>>> used.
>>>>>>
>>>>>> Any information you provide would help.
>>>>>>
>>>>>> Thanks,
>>>>>> Nikita
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>>> For additional commands, e-mail: users-help@...
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>> For additional commands, e-mail: users-help@...
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

Re: Launching Felix 2.0

2009-11-11T17:04:58Z

On 11/11/09 20:00, Nikita Sawant wrote:

> Hi Richard,
>
> I followed the instructions to launch Felix in the link below and am
> able to launch Felix successfully.
>
> Now, I can start and stop the felix instance without any problem.
> When I install a bundle which has a BundleActivator, which is started
> by my host application I cannot activate the bundle, due to a
> ClassCastException:
>
> Caused by: java.lang.ClassCastException: test.MyInterceptorActivator
> at
> org.apache.felix.framework.Felix.createBundleActivator(Felix.java:3525)
> at
> org.apache.felix.framework.Felix.activateBundle(Felix.java:1694)
>
>
> Note that I also have the org.osgi.core bundle installed in the felix
> runtime ( otherwise the bundle I am trying to activate above gives an
> unresolved constraint error for the org.osgi.framework package (
> version >=1.5 ).
>
> There seem to be two different definitions of BundleActivator. How do
> I resolve this issue?

You should not be installing the OSGi core API into the framework, this
will generally always be a bad idea.

There was a bug in Framework 2.0.0 that we were not exporting the
version of the OSGi packages with the correct version...that should fix
your issue.

However, you might want to make sure your bundle actually requires OSGi
R4.2 API, because it is best to specify the lowest possible version you
need.

-> richard

>
> The osgi core I am using is:
>
> org.osgi
> org.osgi.core
> 4.2.0
>
>
> Thanks,
> Nikita
>
> Richard S. Hall wrote:
>> There is a link to our wiki off the "documents" page of the web
>> site...the link to the actual document is:
>>
>>
>> http://cwiki.apache.org/confluence/display/FELIX/Apache+Felix+Framework+Launching+and+Embedding
>>
>>
>> I am not sure why are static site is not syncing with this
>> page...anyone else have any ideas?
>>
>> -> richard
>>
>>
>> On 10/7/09 21:13, Nikita Sawant wrote:
>>> Hi Richard,
>>>
>>> Can you provide me the link to the wiki, I could not find it.
>>>
>>> Thanks,
>>> Nikita
>>>
>>> Richard S. Hall wrote:
>>>> For some reason our wiki is not correctly being exported to create
>>>> our static site, so go directly to the wiki for now since it is up
>>>> to date...unfortunately, the wiki appears to be down right now for
>>>> me, so I can't give you the link.
>>>>
>>>> -> richard
>>>>
>>>>
>>>> On 10/7/09 0:37, Nikita Sawant wrote:
>>>>> Hi Richard,
>>>>>
>>>>> Where can I find documentation on launching Felix 2.0, similar to
>>>>> this
>>>>> <http://felix.apache.org/site/apache-felix-framework-launching-and-embedding.html#ApacheFelixFrameworkLaunchingandEmbedding-standardlauncher>
>>>>>
>>>>>
>>>>> The AutoActivator class has been replaced with AutoProcessor, it
>>>>> is not clear to me how exactly this class is to be configured and
>>>>> used.
>>>>>
>>>>> Any information you provide would help.
>>>>>
>>>>> Thanks,
>>>>> Nikita
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>> For additional commands, e-mail: users-help@...
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

Re: Launching Felix 2.0

2009-11-11T17:00:06Z

Hi Richard,

I followed the instructions to launch Felix in the link below and am
able to launch Felix successfully.

Now, I can start and stop the felix instance without any problem. When
I install a bundle which has a BundleActivator, which is started by my
host application I cannot activate the bundle, due to a ClassCastException:

Caused by: java.lang.ClassCastException: test.MyInterceptorActivator
at
org.apache.felix.framework.Felix.createBundleActivator(Felix.java:3525)
at org.apache.felix.framework.Felix.activateBundle(Felix.java:1694)

Note that I also have the org.osgi.core bundle installed in the felix
runtime ( otherwise the bundle I am trying to activate above gives an
unresolved constraint error for the org.osgi.framework package ( version
>=1.5 ).

There seem to be two different definitions of BundleActivator. How do I
resolve this issue?

The osgi core I am using is:

org.osgi
org.osgi.core
4.2.0

Thanks,
Nikita

Richard S. Hall wrote:

> There is a link to our wiki off the "documents" page of the web
> site...the link to the actual document is:
>
>
> http://cwiki.apache.org/confluence/display/FELIX/Apache+Felix+Framework+Launching+and+Embedding
>
>
> I am not sure why are static site is not syncing with this
> page...anyone else have any ideas?
>
> -> richard
>
>
> On 10/7/09 21:13, Nikita Sawant wrote:
>> Hi Richard,
>>
>> Can you provide me the link to the wiki, I could not find it.
>>
>> Thanks,
>> Nikita
>>
>> Richard S. Hall wrote:
>>> For some reason our wiki is not correctly being exported to create
>>> our static site, so go directly to the wiki for now since it is up
>>> to date...unfortunately, the wiki appears to be down right now for
>>> me, so I can't give you the link.
>>>
>>> -> richard
>>>
>>>
>>> On 10/7/09 0:37, Nikita Sawant wrote:
>>>> Hi Richard,
>>>>
>>>> Where can I find documentation on launching Felix 2.0, similar to
>>>> this
>>>> <http://felix.apache.org/site/apache-felix-framework-launching-and-embedding.html#ApacheFelixFrameworkLaunchingandEmbedding-standardlauncher>
>>>>
>>>>
>>>> The AutoActivator class has been replaced with AutoProcessor, it is
>>>> not clear to me how exactly this class is to be configured and used.
>>>>
>>>> Any information you provide would help.
>>>>
>>>> Thanks,
>>>> Nikita
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

Re: D-Bus

2009-11-11T14:47:49Z

Christopher Armstrong wrote:

> Hi
> [...]
> 1) Compiling the relevant parts of libmatthew. This can be done by
> modifying the Makefiles. Note that you need relevant headers for the
> native code component of libmatthew unix library (the JNI stuff is a
> bit of a pain).
> 2) Compiling DBus-Java for OSGi. Again, it should be reasonably simple
> to generate a Makefile
> 3) You need code that establishes a DBusConnection and can extract
> objects. This is fairly straightforward. The main issue will be if you
> have multiple bundles that need the connection, in which case you will
> have to write some code to publish it into the OSGi service registry
> (its a singleton and behaves as such). You will also need code to
> manage the connection object so that you can withdraw it when the
> connection is dropped).
> 4) DBus-Java Signal handling. Unfortunately, this suffers the same
> problem as a lot of normal Java code, in that it uses reflection to
> determine the signal handling class when it comes time to deliver a
> DBus "signal". The best solution would be to translate the signal
> handlers, within the DBus-Java bundle you create, and then re-publish
> them with an OSGi event handling mechanism such as EventAdmin.
> 5) The component that needs to be communicated with will need Java
> classes generated for its interfaces. There is a tool in DBus-Java to
> do this, and the generated source code files can be easily put into a
> bundle.

Thanks Chris, much appreciated.

I don't think my demo justifies this amount of work,
nevertheless your suggestions will become precious
whenever I'll *have to* integrate OSGi and D-Bus.

Best,
Guido

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

Re: D-Bus

2009-11-11T14:32:18Z

Hi

I have done this before.

I used Java-DBus in a thesis project, and modified it to work on OSGi.
There are multiple issues to sort through, and it really needs a re-
design or compatibility layer to get it to work properly with OSGi.

Some of the things you will need to do:
1) Compiling the relevant parts of libmatthew. This can be done by
modifying the Makefiles. Note that you need relevant headers for the
native code component of libmatthew unix library (the JNI stuff is a
bit of a pain).
2) Compiling DBus-Java for OSGi. Again, it should be reasonably simple
to generate a Makefile
3) You need code that establishes a DBusConnection and can extract
objects. This is fairly straightforward. The main issue will be if you
have multiple bundles that need the connection, in which case you will
have to write some code to publish it into the OSGi service registry
(its a singleton and behaves as such). You will also need code to
manage the connection object so that you can withdraw it when the
connection is dropped).
4) DBus-Java Signal handling. Unfortunately, this suffers the same
problem as a lot of normal Java code, in that it uses reflection to
determine the signal handling class when it comes time to deliver a
DBus "signal". The best solution would be to translate the signal
handlers, within the DBus-Java bundle you create, and then re-publish
them with an OSGi event handling mechanism such as EventAdmin.
5) The component that needs to be communicated with will need Java
classes generated for its interfaces. There is a tool in DBus-Java to
do this, and the generated source code files can be easily put into a
bundle.

Given the amount of work, its not really worth it unless you need to
communicate with an existing component that uses the DBus. For new
code, use something suggested by one of the other authors, especially
if this is for a throw-away demo.

Cheers
Chris

On 28/10/2009, at 12:31 PM, Guido Spadotto wrote:

> Hi all,
> I've searched for this a bit but found nothing useful, so I'm here
> to ask you:
> "Do you know if there's any bundle-ized version of the Java D-Bus
> implementation available somewhere?"
>
> Thanks,
> Guido
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

--------
Christopher Armstrong
carmstrong@...

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

Configurable properties for a custom service are not configurable via the Configuration Console (OSGI Declarative Services - SCR)

2009-11-11T14:13:28Z

On our project we are developing classes that are configurable via the Apache Felix Maven SCR Plugin and Felix Configuration Console. I understand the concept of the scr.property tag and am able to view and edit these properties within the Console Configuration screen. However, I am having trouble with property values that appear to persist when a bundle is updated, but in actuality are not persisted to that property.

For example, I have these two properties in my LDAPManager that is in my Authentication bundle:

/** @scr.property label="Security Principle Password" description="Security principle password" */
private static String SECURITY_CREDENTIALS = "security.credentials";

/** @scr.property label="Authorization Type" description="LDAP Authorization Type" value="Simple"*/
private static String SECURITY_AUTH_TYPE = "security.authorization.type";

When I upload the bundle to Felix and go the configurations tab, I see both of these configurable form fields and auth type is defaulted to "Simple." If I fill out the password form field to "my_password" and hit 'save,' through log files, I am able to see the password field being updated in my code. However, if I go back to my bundles tab and update that bundle (browse to that bundle in the file system, select "install or update", select "refresh packages"), my issue occurs. I notice that if I go to my configurations tab, "my_password" is still filled out/populated in to the password form field but when I check my logs, the property value in the code is set to null. I'm worried that people may assume that the property has been filled out and correct in the code since the form field displays the value but in actuality, the property is still null and won't be set until I hit the save button.

I am populating these fields via the following code:

@SuppressWarnings("unchecked")
protected void activate(ComponentContext context)
{
this.setup(context.getProperties());
}

void setup(Dictionary<String, Object> configuration)
{
Object parameter = configuration.get("password");
userPassword = parameter.toString();
}

Thanks

Re: Bundle.findEntries(...) and Bundle-Classpath

2009-11-11T09:56:23Z

On 11/11/09 10:20, lukewpatterson wrote:

>
> Richard S. Hall wrote:
>
>>
>>> I'm just trying to understand how the
>>> "contents of the contents", as you put it, aren't included in "the
>>> contents".
>>>
>>>
>> Just think of how you manually unzip an archive. If you unzip it, you
>> get its contents. If the contents contain other zip files, they still
>> need to be unzip to see what is inside of them. Unzipping is not
>> recursive.
>>
>>
> My analogy with the Matryoshka doll wasn't very good. Like you said, it
> isn't recursive. It is nested/embedded at most one level deep.
>
>
> Richard S. Hall wrote:
>
>> On 11/10/09 19:38, lukewpatterson wrote:
>>
>>> So entries in the "Bundle Space" (v4.2, sec. 4.4.14) aren't retrieved
>>> from
>>> the "Bundle Class Path" (v4.2, sec. 3.8.1)? Am I missing something
>>> conceptual or fundamental?
>>>
>>>
>> Correct. The term "entry" was used to correlate to the terminology of
>> ZipFile/JarFile.getEntry(). In OSGi the entry-related methods are
>> intended to give access to the "raw content" of the bundle.
>>
>>
> Now it makes more sense. I could use the "entry" methods to retrieve the
> actual embedded jar files, for example.
>

Yes.

-> richard

> In my scenario, I'm trying to detect the presence of "META-INF/services/*"
> resources which would be present in the "Bundle Space" without resolving.
> In my bundletracking, I don't want to resolve every bundle I find. (I
> shouldn't have been trying to use findEntries anyway, cause that resolves)
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

Re: Bundle.findEntries(...) and Bundle-Classpath

2009-11-11T07:37:30Z

Jeremias Maerki-2 wrote:

On 10.11.2009 18:26:37 lukewpatterson wrote:
>
> In my activator, I'm bundletracking looking for /META-INF/services folders.
> I wrap around the service-providing bundles with a custom ClassLoader and
> then register them with my API's service factory.
>
> This approach seems to work fine except when the /META-INF/services are
> provided exclusively from the Bundle-ClassPath entries. i.e. doesn't work
> when no /META-INF/services folder on root, but embedded jars on the
> Bundle-ClassPath have the folder
>
> Is Bundle.findEntries(...) [1] supposed to look on the Bundle-Classpath?

Are you trying to solve the same problem as I've done lately?
See: http://www.jeremias-maerki.ch/development/osgi/jar-services.html
Well, I didn't specifically look into the Bundle-Classpath issue in this
context. I've turned the META-INF/services carrying JARs into full OSGi
bundles.

Yes Jeremias, I think what you've done is very close to what I'm looking for. I think the restlet team is doing something kinda like this too [1].

I'm working with other teams which use jar SPI (they are kind enough to make their stuff bundles, but don't care about OSGi beyond that point), and I want a generic way of loading impls. The dynamism obviously wouldn't be there, so I was thinking that the appropriate level of bundle state required would merely be INSTALLED.

I started reading through your code and documentation. I was wondering if it handles all the scenarios where a bundle can be updated, installed, uninstalled.

I was hoping to accomplish this generic lookup without requiring a special manifest header, but I see how that introduces all sorts of complexities for the implementation (even with BundleTracker and PackageAdmin).

[1] http://n2.nabble.com/OSGi-vs-Service-Provider-patterns-td2478338.html and http://restlet.tigris.org/source/browse/restlet/trunk/modules/org.restlet/src/org/restlet/engine/internal/Activator.java?view=markup and

Re: Bundle.findEntries(...) and Bundle-Classpath

2009-11-11T07:20:07Z

Richard S. Hall wrote:

> I'm just trying to understand how the
> "contents of the contents", as you put it, aren't included in "the
> contents".
>

Just think of how you manually unzip an archive. If you unzip it, you
get its contents. If the contents contain other zip files, they still
need to be unzip to see what is inside of them. Unzipping is not recursive.

My analogy with the Matryoshka doll wasn't very good. Like you said, it isn't recursive. It is nested/embedded at most one level deep.

Richard S. Hall wrote:

On 11/10/09 19:38, lukewpatterson wrote:
> So entries in the "Bundle Space" (v4.2, sec. 4.4.14) aren't retrieved from
> the "Bundle Class Path" (v4.2, sec. 3.8.1)? Am I missing something
> conceptual or fundamental?
>

Correct. The term "entry" was used to correlate to the terminology of
ZipFile/JarFile.getEntry(). In OSGi the entry-related methods are
intended to give access to the "raw content" of the bundle.

Now it makes more sense. I could use the "entry" methods to retrieve the actual embedded jar files, for example.

In my scenario, I'm trying to detect the presence of "META-INF/services/*" resources which would be present in the "Bundle Space" without resolving. In my bundletracking, I don't want to resolve every bundle I find. (I shouldn't have been trying to use findEntries anyway, cause that resolves)

javax.xml.bind classes (JDK 1.6) - Apache Felix Karaf 1.0.0 - Apache CXF 2.2

2009-11-11T00:21:18Z

I would like to know if we have to export (or not) the javax.xml.bind*
packages defined in the file config.properties file of Apache Felix
2.2 when I would like to use Apache CXF. By default, they are exported
but I have an unresolved constraint issue when deploying bundles
required fro CXF 2.2 and especially for the following bundle :

mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.jaxb-impl/2.1.6_1

This bundle requires the packages
javax.xml.bind;version="2.1",javax.xml.bind.annotation;ver
sion="2.1",javax.xml.bind.annotation.adapters;version="2.1",javax.xml
.bind.attachment;version="2.1",javax.xml.bind.helpers;version="2.1"

I see using the command exports that these packages are exported but
though the version 0.0

Remark : in ServiceMix 4.xxx, they are not exported. In this case,
which jar file export those required packages ?

Regards,

Charles Moulliard
Senior Enterprise Architect
Apache Camel Committer

*****************************
blog : http://cmoulliard.blogspot.com
twitter : http://twitter.com/cmoulliard

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

Charles Moulliard
SOA Architect

My Blog : http://cmoulliard.blogspot.com/

Re: Bundle.findEntries(...) and Bundle-Classpath

2009-11-10T23:34:10Z

Are you trying to solve the same problem as I've done lately?
See: http://www.jeremias-maerki.ch/development/osgi/jar-services.html
Well, I didn't specifically look into the Bundle-Classpath issue in this
context. I've turned the META-INF/services carrying JARs into full OSGi
bundles.

On 10.11.2009 18:26:37 lukewpatterson wrote:

>
> In my activator, I'm bundletracking looking for /META-INF/services folders.
> I wrap around the service-providing bundles with a custom ClassLoader and
> then register them with my API's service factory.
>
> This approach seems to work fine except when the /META-INF/services are
> provided exclusively from the Bundle-ClassPath entries. i.e. doesn't work
> when no /META-INF/services folder on root, but embedded jars on the
> Bundle-ClassPath have the folder
>
> Is Bundle.findEntries(...) [1] supposed to look on the Bundle-Classpath?
>
>
> Thanks,
>
> Luke
>
>
> [1]
> http://www.osgi.org/javadoc/r4v41/org/osgi/framework/Bundle.html#findEntries%28java.lang.String,%20java.lang.String,%20boolean%29
> --
> View this message in context: http://old.nabble.com/Bundle.findEntries%28...%29-and-Bundle-Classpath-tp26287340p26287340.html
> Sent from the Apache Felix - Users mailing list archive at Nabble.com.
>

Jeremias Maerki

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

Re: Bundle.findEntries(...) and Bundle-Classpath

2009-11-10T16:44:19Z

On 11/10/09 19:38, lukewpatterson wrote:

>
> Richard S. Hall wrote:
>
>> since you are confused
>>
>>
> Yes I truly am confused. :) But this mailing list seems pretty responsive
> and welcoming, so I think I'm on the path to figuring things out.
>
> So entries in the "Bundle Space" (v4.2, sec. 4.4.14) aren't retrieved from
> the "Bundle Class Path" (v4.2, sec. 3.8.1)? Am I missing something
> conceptual or fundamental?
>

Correct. The term "entry" was used to correlate to the terminology of
ZipFile/JarFile.getEntry(). In OSGi the entry-related methods are
intended to give access to the "raw content" of the bundle.

> I'm not trying to be difficult, I'm just trying to understand how the
> "contents of the contents", as you put it, aren't included in "the
> contents".
>

Just think of how you manually unzip an archive. If you unzip it, you
get its contents. If the contents contain other zip files, they still
need to be unzip to see what is inside of them. Unzipping is not recursive.

-> richard

>
> Thanks,
>
> Luke
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

Re: Bundle.findEntries(...) and Bundle-Classpath

2009-11-10T16:38:44Z

Richard S. Hall wrote:

since you are confused

Yes I truly am confused. :) But this mailing list seems pretty responsive and welcoming, so I think I'm on the path to figuring things out.

So entries in the "Bundle Space" (v4.2, sec. 4.4.14) aren't retrieved from the "Bundle Class Path" (v4.2, sec. 3.8.1)? Am I missing something conceptual or fundamental?

I'm not trying to be difficult, I'm just trying to understand how the "contents of the contents", as you put it, aren't included in "the contents".

Thanks,

Luke

Re: Bundle.findEntries(...) and Bundle-Classpath

2009-11-10T14:24:21Z

On 11/10/09 16:57, lukewpatterson wrote:

>
> Richard S. Hall wrote:
>
>>
>>
>> On 11/10/09 14:38, lukewpatterson wrote:
>>
>>> Stuart McCulloch wrote:
>>>
>>>
>>>> as the Bundle.findEntries() javadoc states:
>>>>
>>>> "This bundle's class loader is not used to search for entries"
>>>>
>>>> so it won't look inside embedded jars - you'll need to use
>>>> Bundle.getResource() / getResources() for that
>>>>
>>>>
>>>>
>>> The part that was confusing me was "Only the contents of this bundle and
>>> its
>>> attached fragments are searched for the specified entries.". I thought
>>> embedded jars on the Bundle-Classpath would qualify as "contents of this
>>> bundle".
>>>
>>>
>> That would be the contents of the contents. :-)
>>
>>
>>
> :) Which does the smiley face mean:
>
> A) the current behavior is correct and properly documented
> B) the current behavior is correct but the documentation is misleading (or
> potentially misleading)
> C) the current behavior is incorrect and the documentation is correct
>
> 'A' doesn't make sense to me, and I don't think it would make sense to
> anyone else who has seen a Matryoshka doll.
>
> I'm guessing 'B', but I hope it is 'C', cause then it could be "fixed". :)
>

Well, for me, it is 'A', but since you are confused, I guess it is 'B'. :-)

-> richard

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

Re: Bundle.findEntries(...) and Bundle-Classpath

2009-11-10T13:57:30Z

Richard S. Hall wrote:

On 11/10/09 14:38, lukewpatterson wrote:
>
> Stuart McCulloch wrote:
>
>> as the Bundle.findEntries() javadoc states:
>>
>> "This bundle's class loader is not used to search for entries"
>>
>> so it won't look inside embedded jars - you'll need to use
>> Bundle.getResource() / getResources() for that
>>
>>
> The part that was confusing me was "Only the contents of this bundle and its
> attached fragments are searched for the specified entries.". I thought
> embedded jars on the Bundle-Classpath would qualify as "contents of this
> bundle".
>

That would be the contents of the contents. :-)

:) Which does the smiley face mean:

A) the current behavior is correct and properly documented
B) the current behavior is correct but the documentation is misleading (or potentially misleading)
C) the current behavior is incorrect and the documentation is correct

'A' doesn't make sense to me, and I don't think it would make sense to anyone else who has seen a Matryoshka doll.

I'm guessing 'B', but I hope it is 'C', cause then it could be "fixed". :)

Re: Bundle.findEntries(...) and Bundle-Classpath

2009-11-10T11:55:32Z

On 11/10/09 14:38, lukewpatterson wrote:

>
> Stuart McCulloch wrote:
>
>> as the Bundle.findEntries() javadoc states:
>>
>> "This bundle's class loader is not used to search for entries"
>>
>> so it won't look inside embedded jars - you'll need to use
>> Bundle.getResource() / getResources() for that
>>
>>
> The part that was confusing me was "Only the contents of this bundle and its
> attached fragments are searched for the specified entries.". I thought
> embedded jars on the Bundle-Classpath would qualify as "contents of this
> bundle".
>

That would be the contents of the contents. :-)

> With Bundle.getResource() / getResources(), it could potentially find
> resources from other bundles, right?
>

Yes. This delegates first before searching bundle class path.

-> richard

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

Re: Bundle.findEntries(...) and Bundle-Classpath

2009-11-10T11:38:02Z

Stuart McCulloch wrote:

as the Bundle.findEntries() javadoc states:

"This bundle's class loader is not used to search for entries"

so it won't look inside embedded jars - you'll need to use
Bundle.getResource() / getResources() for that

The part that was confusing me was "Only the contents of this bundle and its attached fragments are searched for the specified entries.". I thought embedded jars on the Bundle-Classpath would qualify as "contents of this bundle".

With Bundle.getResource() / getResources(), it could potentially find resources from other bundles, right?

Re: Bundle.findEntries(...) and Bundle-Classpath

2009-11-10T09:37:19Z

2009/11/11 lukewpatterson <lukewpatterson@...>

as the Bundle.findEntries() javadoc states:

"This bundle's class loader is not used to search for entries"

so it won't look inside embedded jars - you'll need to use
Bundle.getResource() / getResources() for that

> Thanks,
>
> Luke
>
>
> [1]
>
> http://www.osgi.org/javadoc/r4v41/org/osgi/framework/Bundle.html#findEntries%28java.lang.String,%20java.lang.String,%20boolean%29
> --
> View this message in context:
> http://old.nabble.com/Bundle.findEntries%28...%29-and-Bundle-Classpath-tp26287340p26287340.html
> Sent from the Apache Felix - Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

--
Cheers, Stuart

Bundle.findEntries(...) and Bundle-Classpath

2009-11-10T09:26:35Z

In my activator, I'm bundletracking looking for /META-INF/services folders. I wrap around the service-providing bundles with a custom ClassLoader and then register them with my API's service factory.

This approach seems to work fine except when the /META-INF/services are provided exclusively from the Bundle-ClassPath entries. i.e. doesn't work when no /META-INF/services folder on root, but embedded jars on the Bundle-ClassPath have the folder

Is Bundle.findEntries(...) [1] supposed to look on the Bundle-Classpath?

Thanks,

Luke

[1] http://www.osgi.org/javadoc/r4v41/org/osgi/framework/Bundle.html#findEntries%28java.lang.String,%20java.lang.String,%20boolean%29

Re: Declarative Services, loading from
2009-11-10T09:04:24Z

Felix Meschberger-2 wrote:

In this case I suggest you declare your bundle with lazy activation
policy and just start the bundles. The bundles will then not really be
started.

Thanks Felix. I think I'll have to go a slightly different route than DS cause in the downstream deployed products I won't have control over which bundles are started and I don't want to unnecessarily start (programmatically) any bundles.

Luke