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

[lukewpatterson]

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

[Stuart McCulloch]

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

>
> 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?
>

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

[lukewpatterson]

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?

[Richard S. Hall]

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@...

[lukewpatterson]

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". :)

[Richard S. Hall]

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@...

[lukewpatterson]

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

[Richard S. Hall]

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@...

[Jeremias Maerki-2]

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@...

[lukewpatterson]

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)

[lukewpatterson]

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

[Richard S. Hall]

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@...

[Jeremias Maerki-2]

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@...

[lukewpatterson]

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?

[Jeremias Maerki-2]

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@...