You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Jeff McAffer <Je...@ca.ibm.com> on 2006/09/11 02:15:00 UTC
Re: Felix problem on jamvm/NSLU2
OSGi on a Slug is definitely feasible. Tom Watson and I demonstrated this
with Equinox at OSGi World Congress last year. Check out the movies at
http://www.eclipse.org/equinox/documents/
There is plenty of room on devices like the Slug.
Jeff
"Michael E. Brown" <mi...@mindspring.com>
08/27/2006 06:46 PM
Please respond to
felix-dev@incubator.apache.org
To
felix-dev@incubator.apache.org
cc
Subject
Re: Felix problem on jamvm/NSLU2
I had Oscar running with JamVM on the SLUG about a year ago using the
links I posted earlier.
Mike
Niclas Hedhman wrote:
>On Saturday 26 August 2006 21:29, Alex Karasulu wrote:
>
>
>>Niclas Hedhman wrote:
>>
>>
>>>On Thursday 24 August 2006 17:41, Arnaud Quiblier wrote:
>>>
>>>
>>>>I know that Petere Kriens played with Slug too. Dont' know wheteher he
>>>>succeeds in, but he woud be interested in people playing around Slug.
>>>>
>>>>Here is the post :
>>>>http://www.aqute.biz/2005/10/osgi-on-slug.html
>>>>
>>>>
>>>I happened to come across this project. Maybe it interests someone;
>>>
>>>https://opensource.luminis.net/confluence/display/WONKA/Home
>>>
>>>
>>Does this run on the SLUG?
>>
>>
>
>Don't know, but I think it would be possible to make it run on the SLUG
and
>probably smaller than devices, if one starts ripping out subsystems.
>
>
>Cheers
>Niclas
>
>
>
--
"If I have the belief that I can do it, I shall surely acquire the
capacity to do it even if I may not have it at the beginning."
- Mahatma Gandhi
Re: Small bug...
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Oops. Yep, I missed that one. Thanks.
It is committed.
-> richard
Olivier Gruber wrote:
> Just stumbled on a small bug
>
> public FindEntriesEnumeration(Felix felix,
> BundleImpl bundle, String path, String filePattern, boolean
> recurse)
> {
> m_felix = felix;
> m_bundle = bundle;
> m_path = path;
> m_enumeration = m_bundle.getInfo().getCurrentModule()
> .getContentLoader().getContent().getEntries();
> m_recurse = recurse;
>
> // Sanity check the parameters.
> if (m_path == null)
> {
> throw new IllegalArgumentException("The path for findEntries()
> cannot be null.");
> }
> // Strip leading '/' if present.
> if ((m_path.length() > 0) && (m_path.charAt(0) == '/'))
> {
> m_path = m_path.substring(1);
> }
> // Add a '/' to the end if not present.
> ==> if ((m_path.length() > 0) && (m_path.charAt(path.length() - 1) !=
> '/'))
> { ****
> m_path = m_path + "/";
> }
>
> // File pattern defaults to "*" if not specified.
> filePattern = (filePattern == null) ? "*" : filePattern;
>
> m_filePattern = parseSubstring(filePattern);
>
> m_next = findNext();
> }
>
> It should not mix path and m_path... on a path like /META-INF/Foo/
> it fails raising a StringIndexOutOfBoundsException
> Here is the fix:
>
> ==> if ((m_path.length() > 0) && (m_path.charAt(m_path.length() - 1)
> != '/'))
> _______
>
> Cheers,
>
> Olivier Gruber, Ph.D.
> Persistent & Distributed Object Platforms and Frameworks
> IBM TJ Watson Research Center
>
>
>
Re: Bundle.getResources
Posted by "Richard S. Hall" <he...@ungoverned.org>.
This is on the "to do" list somewhere...I think it might need some
changes to the underlying module abstractions since they don't currently
support this operation, i.e., they have getResource() but not
getResources().
I am not currently working on it, so if you want to look at it feel free.
This is related to JIRA issue FELIX-31...
-> richard
Olivier Gruber wrote:
> I just realized that Bundle.getResources(String) is not implemented,
> anyone looking into this or should I ?
>
> Regards,
>
> Olivier Gruber, Ph.D.
> Persistent & Distributed Object Platforms and Frameworks
> IBM TJ Watson Research Center
>
>
>
Bundle.getResources
Posted by Olivier Gruber <og...@us.ibm.com>.
I just realized that Bundle.getResources(String) is not implemented,
anyone looking into this or should I ?
Regards,
Olivier Gruber, Ph.D.
Persistent & Distributed Object Platforms and Frameworks
IBM TJ Watson Research Center
Small bug...
Posted by Olivier Gruber <og...@us.ibm.com>.
Just stumbled on a small bug
public FindEntriesEnumeration(Felix felix,
BundleImpl bundle, String path, String filePattern, boolean
recurse)
{
m_felix = felix;
m_bundle = bundle;
m_path = path;
m_enumeration = m_bundle.getInfo().getCurrentModule()
.getContentLoader().getContent().getEntries();
m_recurse = recurse;
// Sanity check the parameters.
if (m_path == null)
{
throw new IllegalArgumentException("The path for findEntries()
cannot be null.");
}
// Strip leading '/' if present.
if ((m_path.length() > 0) && (m_path.charAt(0) == '/'))
{
m_path = m_path.substring(1);
}
// Add a '/' to the end if not present.
==> if ((m_path.length() > 0) && (m_path.charAt(path.length() - 1) !=
'/'))
{ ****
m_path = m_path + "/";
}
// File pattern defaults to "*" if not specified.
filePattern = (filePattern == null) ? "*" : filePattern;
m_filePattern = parseSubstring(filePattern);
m_next = findNext();
}
It should not mix path and m_path... on a path like /META-INF/Foo/
it fails raising a StringIndexOutOfBoundsException
Here is the fix:
==> if ((m_path.length() > 0) && (m_path.charAt(m_path.length() - 1)
!= '/'))
_______
Cheers,
Olivier Gruber, Ph.D.
Persistent & Distributed Object Platforms and Frameworks
IBM TJ Watson Research Center
Re: Bundle.getResources
Posted by "Richard S. Hall" <he...@ungoverned.org>.
I can agree with this.
-> richard
Olivier Gruber wrote:
> The parent class loader was done, I just forgot to mention it.
> Indeed, I was not mention require-bundle and split-packages
> because neither are an issue in Felix as of now.
>
> Therefore, I maintain that we should follow the semantics of classloading
> and therefore have imports shadowing local class path. In other words,
> we get the resources either from a corresponding import or from the local
> class path.
>
> I will submit a patch in the corresponding JIRA.
> Best regards,
>
> Olivier Gruber, Ph.D.
> Persistent & Distributed Object Platforms and Frameworks
> IBM TJ Watson Research Center
>
> "If at first the idea is not absurd, then there is no hope for it."
> Albert Einstein
>
>
>
>
>
>
> "Richard S. Hall" <he...@ungoverned.org>
> 09/22/2006 04:15 PM
> Please respond to
> felix-dev@incubator.apache.org
>
>
> To
> felix-dev@incubator.apache.org
> cc
>
> Subject
> Re: Bundle.getResources
>
>
>
>
>
>
> Well, we have not implemented require-bundle yet, which is why he is
> probably not considering that, but you are right. I too was going to
> point out parent class loaders...
>
> -> richard
>
> Jeff McAffer wrote:
>
>> getResource*() should follow exactly the same rules as classloading. You
>>
>
>
>> have not considered Require-Bundle or parent classloaders. This can
>> result in resources from many bundles (split packages). Take a look at
>> BundleLoader.findResources(String) in the reference implementation. It
>> enumerates the steps for finding resources.
>>
>> Jeff
>>
>>
>>
>>
>> Olivier Gruber <og...@us.ibm.com>
>> 09/22/2006 05:59 AM
>> Please respond to
>> felix-dev@incubator.apache.org
>>
>>
>> To
>> felix-dev@incubator.apache.org
>> cc
>>
>> Subject
>> Bundle.getResources
>>
>>
>>
>>
>>
>>
>> I am implementing the Bundle.getResources(String)
>> and I want to confirm something.
>>
>> Assuming the bundle is resolved, we are looking in
>>
>> - its imports
>> - its local class path
>> - we retry to satisfy dynamic imports in case it would yield
>> something.
>>
>> So that's all fine. Now the tricky question: if we find something from
>>
> an
>
>> import,
>> should we continue or not? I believe we should not continue, here is
>>
> why.
>
>> If it is found from an import, this means that the resource is from a
>>
> Java
>
>> package
>> (otherwise, it would not be found as part of an import). It seems to me
>> that we want
>> a consistent behavior with class loading. If a class is search for and
>>
> its
>
>> package
>> is an import, we do not look in the local class path in case of failure
>> loading from
>> the import.
>>
>> So I have implemented getResources in the same way.
>>
>> If it finds that the path to the resource is an imported package, it
>>
> will
>
>> attempt
>> loading from this import. If it succeeds, it stops there, the local
>>
> class
>
>> path
>> is not considered. The import has or has no corresponding resources
>>
> (0,1,
>
>> or more).
>>
>> If it does not match an imported package, the local class path is
>> search and 0,1 or more resource may be found locally.
>>
>> Another way to say this is that all the various resources found will be
>> from a single bundle. Either they will be local resources, solely from
>> this
>> bundle on which we called getResources(). Or the resources will be
>> solely from the bundle used to satisfy the import of the corresponding
>> package.
>> It all depends if the path to the resources is an imported package or
>>
> not.
>
>> Comments?
>>
>> Olivier Gruber, Ph.D.
>> Persistent & Distributed Object Platforms and Frameworks
>> IBM TJ Watson Research Center
>>
>>
>>
>>
>>
>
>
>
Re: Bundle.getResources
Posted by Olivier Gruber <og...@us.ibm.com>.
The parent class loader was done, I just forgot to mention it.
Indeed, I was not mention require-bundle and split-packages
because neither are an issue in Felix as of now.
Therefore, I maintain that we should follow the semantics of classloading
and therefore have imports shadowing local class path. In other words,
we get the resources either from a corresponding import or from the local
class path.
I will submit a patch in the corresponding JIRA.
Best regards,
Olivier Gruber, Ph.D.
Persistent & Distributed Object Platforms and Frameworks
IBM TJ Watson Research Center
"If at first the idea is not absurd, then there is no hope for it."
Albert Einstein
"Richard S. Hall" <he...@ungoverned.org>
09/22/2006 04:15 PM
Please respond to
felix-dev@incubator.apache.org
To
felix-dev@incubator.apache.org
cc
Subject
Re: Bundle.getResources
Well, we have not implemented require-bundle yet, which is why he is
probably not considering that, but you are right. I too was going to
point out parent class loaders...
-> richard
Jeff McAffer wrote:
> getResource*() should follow exactly the same rules as classloading. You
> have not considered Require-Bundle or parent classloaders. This can
> result in resources from many bundles (split packages). Take a look at
> BundleLoader.findResources(String) in the reference implementation. It
> enumerates the steps for finding resources.
>
> Jeff
>
>
>
>
> Olivier Gruber <og...@us.ibm.com>
> 09/22/2006 05:59 AM
> Please respond to
> felix-dev@incubator.apache.org
>
>
> To
> felix-dev@incubator.apache.org
> cc
>
> Subject
> Bundle.getResources
>
>
>
>
>
>
> I am implementing the Bundle.getResources(String)
> and I want to confirm something.
>
> Assuming the bundle is resolved, we are looking in
>
> - its imports
> - its local class path
> - we retry to satisfy dynamic imports in case it would yield
> something.
>
> So that's all fine. Now the tricky question: if we find something from
an
> import,
> should we continue or not? I believe we should not continue, here is
why.
>
> If it is found from an import, this means that the resource is from a
Java
>
> package
> (otherwise, it would not be found as part of an import). It seems to me
> that we want
> a consistent behavior with class loading. If a class is search for and
its
>
> package
> is an import, we do not look in the local class path in case of failure
> loading from
> the import.
>
> So I have implemented getResources in the same way.
>
> If it finds that the path to the resource is an imported package, it
will
> attempt
> loading from this import. If it succeeds, it stops there, the local
class
> path
> is not considered. The import has or has no corresponding resources
(0,1,
> or more).
>
> If it does not match an imported package, the local class path is
> search and 0,1 or more resource may be found locally.
>
> Another way to say this is that all the various resources found will be
> from a single bundle. Either they will be local resources, solely from
> this
> bundle on which we called getResources(). Or the resources will be
> solely from the bundle used to satisfy the import of the corresponding
> package.
> It all depends if the path to the resources is an imported package or
not.
>
> Comments?
>
> Olivier Gruber, Ph.D.
> Persistent & Distributed Object Platforms and Frameworks
> IBM TJ Watson Research Center
>
>
>
>
Re: Bundle.getResources
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Well, we have not implemented require-bundle yet, which is why he is
probably not considering that, but you are right. I too was going to
point out parent class loaders...
-> richard
Jeff McAffer wrote:
> getResource*() should follow exactly the same rules as classloading. You
> have not considered Require-Bundle or parent classloaders. This can
> result in resources from many bundles (split packages). Take a look at
> BundleLoader.findResources(String) in the reference implementation. It
> enumerates the steps for finding resources.
>
> Jeff
>
>
>
>
> Olivier Gruber <og...@us.ibm.com>
> 09/22/2006 05:59 AM
> Please respond to
> felix-dev@incubator.apache.org
>
>
> To
> felix-dev@incubator.apache.org
> cc
>
> Subject
> Bundle.getResources
>
>
>
>
>
>
> I am implementing the Bundle.getResources(String)
> and I want to confirm something.
>
> Assuming the bundle is resolved, we are looking in
>
> - its imports
> - its local class path
> - we retry to satisfy dynamic imports in case it would yield
> something.
>
> So that's all fine. Now the tricky question: if we find something from an
> import,
> should we continue or not? I believe we should not continue, here is why.
>
> If it is found from an import, this means that the resource is from a Java
>
> package
> (otherwise, it would not be found as part of an import). It seems to me
> that we want
> a consistent behavior with class loading. If a class is search for and its
>
> package
> is an import, we do not look in the local class path in case of failure
> loading from
> the import.
>
> So I have implemented getResources in the same way.
>
> If it finds that the path to the resource is an imported package, it will
> attempt
> loading from this import. If it succeeds, it stops there, the local class
> path
> is not considered. The import has or has no corresponding resources (0,1,
> or more).
>
> If it does not match an imported package, the local class path is
> search and 0,1 or more resource may be found locally.
>
> Another way to say this is that all the various resources found will be
> from a single bundle. Either they will be local resources, solely from
> this
> bundle on which we called getResources(). Or the resources will be
> solely from the bundle used to satisfy the import of the corresponding
> package.
> It all depends if the path to the resources is an imported package or not.
>
> Comments?
>
> Olivier Gruber, Ph.D.
> Persistent & Distributed Object Platforms and Frameworks
> IBM TJ Watson Research Center
>
>
>
>
Re: Bundle.getResources
Posted by Jeff McAffer <Je...@ca.ibm.com>.
getResource*() should follow exactly the same rules as classloading. You
have not considered Require-Bundle or parent classloaders. This can
result in resources from many bundles (split packages). Take a look at
BundleLoader.findResources(String) in the reference implementation. It
enumerates the steps for finding resources.
Jeff
Olivier Gruber <og...@us.ibm.com>
09/22/2006 05:59 AM
Please respond to
felix-dev@incubator.apache.org
To
felix-dev@incubator.apache.org
cc
Subject
Bundle.getResources
I am implementing the Bundle.getResources(String)
and I want to confirm something.
Assuming the bundle is resolved, we are looking in
- its imports
- its local class path
- we retry to satisfy dynamic imports in case it would yield
something.
So that's all fine. Now the tricky question: if we find something from an
import,
should we continue or not? I believe we should not continue, here is why.
If it is found from an import, this means that the resource is from a Java
package
(otherwise, it would not be found as part of an import). It seems to me
that we want
a consistent behavior with class loading. If a class is search for and its
package
is an import, we do not look in the local class path in case of failure
loading from
the import.
So I have implemented getResources in the same way.
If it finds that the path to the resource is an imported package, it will
attempt
loading from this import. If it succeeds, it stops there, the local class
path
is not considered. The import has or has no corresponding resources (0,1,
or more).
If it does not match an imported package, the local class path is
search and 0,1 or more resource may be found locally.
Another way to say this is that all the various resources found will be
from a single bundle. Either they will be local resources, solely from
this
bundle on which we called getResources(). Or the resources will be
solely from the bundle used to satisfy the import of the corresponding
package.
It all depends if the path to the resources is an imported package or not.
Comments?
Olivier Gruber, Ph.D.
Persistent & Distributed Object Platforms and Frameworks
IBM TJ Watson Research Center
Bundle.getResources
Posted by Olivier Gruber <og...@us.ibm.com>.
I am implementing the Bundle.getResources(String)
and I want to confirm something.
Assuming the bundle is resolved, we are looking in
- its imports
- its local class path
- we retry to satisfy dynamic imports in case it would yield
something.
So that's all fine. Now the tricky question: if we find something from an
import,
should we continue or not? I believe we should not continue, here is why.
If it is found from an import, this means that the resource is from a Java
package
(otherwise, it would not be found as part of an import). It seems to me
that we want
a consistent behavior with class loading. If a class is search for and its
package
is an import, we do not look in the local class path in case of failure
loading from
the import.
So I have implemented getResources in the same way.
If it finds that the path to the resource is an imported package, it will
attempt
loading from this import. If it succeeds, it stops there, the local class
path
is not considered. The import has or has no corresponding resources (0,1,
or more).
If it does not match an imported package, the local class path is
search and 0,1 or more resource may be found locally.
Another way to say this is that all the various resources found will be
from a single bundle. Either they will be local resources, solely from
this
bundle on which we called getResources(). Or the resources will be
solely from the bundle used to satisfy the import of the corresponding
package.
It all depends if the path to the resources is an imported package or not.
Comments?
Olivier Gruber, Ph.D.
Persistent & Distributed Object Platforms and Frameworks
IBM TJ Watson Research Center
Re: Bug in Bundle.getEntry ?
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Sounds related. I will crosscheck them when I resolve it.
-> richard
santillan wrote:
> Has this got something to do with FELIX-143?
>
> --
>
> Manuel Santillán <sa...@dit.upm.es>
>
> http://www.dit.upm.es/santillan
>
> Departamento de Ingeniería de Sistemas Telemáticos
>
> Escuela Técnica Superior de Ingenieros de Telecomunicación
>
> Universidad Politécnica de Madrid
>
> Avda. Complutense, s/n
>
> 28040 Madrid SPAIN
>
> Tel. +34 913367366 ext.3034
>
> -----Mensaje original-----
> De: Richard S. Hall [mailto:heavy@ungoverned.org]
> Enviado el: martes, 19 de septiembre de 2006 18:21
> Para: felix-dev@incubator.apache.org
> Asunto: Re: Bug in Bundle.getEntry ?
>
> The patch appears to not have been attached to the message...
>
> Better yet, perhaps you could create a JIRA issue for this on the
> framework component and attach the patch to it.
>
> http://issues.apache.org/jira/browse/Felix
>
> Thanks.
>
> -> richard
>
>
>
> Olivier Gruber wrote:
>
>> I think I found a bug in the implementation of URL
>> Bundle.getEntry(String name);
>> It raises a ClassCastException when called on the system bundle since
>> its content loader
>> is not a ContentLoaderImpl but actually a SystemBundleContentLoader. :-(
>>
>> *class BundleImpl *
>> * public* URL getEntry(String name)
>> {
>> Object sm = System./getSecurityManager/();
>>
>> *if* (sm != *null*)
>> {
>> *try*
>> {
>> ((SecurityManager) sm).checkPermission(*new*
>> AdminPermission(*this*,
>> AdminPermission./RESOURCE/));
>> }
>> *catch* (Exception e)
>> {
>> *return* *null*; // No permission
>> }
>> }
>>
>> *return* m_felix.getBundleEntry(*this*, name);
>> }
>>
>> *class Felix*
>> /**
>> * Implementation for Bundle.getEntry().
>> **/
>> *protected* URL getBundleEntry(BundleImpl bundle, String name)
>> {
>> *if* (bundle.getInfo().getState() == Bundle./UNINSTALLED/)
>> {
>> *throw* *new* IllegalStateException("The bundle is
>> uninstalled.");
>> }
>> ==>> *return* ((ContentLoaderImpl)
>> bundle.getInfo().getCurrentModule()
>> .getContentLoader()).getResourceFromContent(name);
>> }
>>
>> Here is a patch for this problem.
>>
>>
>>
>> It is basically moving the getResourceFromContent from
>> ContentLoaderImpl to Felix,
>> which required to modify the FindEntriesEnumeration slightly.
>>
>> Best regards,
>>
>> Olivier Gruber, Ph.D.
>> Persistent & Distributed Object Platforms and Frameworks
>> IBM TJ Watson Research Center
>>
>>
>
>
RE: Bug in Bundle.getEntry ?
Posted by santillan <sa...@dit.upm.es>.
Has this got something to do with FELIX-143?
--
Manuel Santillán <sa...@dit.upm.es>
http://www.dit.upm.es/santillan
Departamento de Ingeniería de Sistemas Telemáticos
Escuela Técnica Superior de Ingenieros de Telecomunicación
Universidad Politécnica de Madrid
Avda. Complutense, s/n
28040 Madrid SPAIN
Tel. +34 913367366 ext.3034
-----Mensaje original-----
De: Richard S. Hall [mailto:heavy@ungoverned.org]
Enviado el: martes, 19 de septiembre de 2006 18:21
Para: felix-dev@incubator.apache.org
Asunto: Re: Bug in Bundle.getEntry ?
The patch appears to not have been attached to the message...
Better yet, perhaps you could create a JIRA issue for this on the
framework component and attach the patch to it.
http://issues.apache.org/jira/browse/Felix
Thanks.
-> richard
Olivier Gruber wrote:
>
> I think I found a bug in the implementation of URL
> Bundle.getEntry(String name);
> It raises a ClassCastException when called on the system bundle since
> its content loader
> is not a ContentLoaderImpl but actually a SystemBundleContentLoader. :-(
>
> *class BundleImpl *
> * public* URL getEntry(String name)
> {
> Object sm = System./getSecurityManager/();
>
> *if* (sm != *null*)
> {
> *try*
> {
> ((SecurityManager) sm).checkPermission(*new*
> AdminPermission(*this*,
> AdminPermission./RESOURCE/));
> }
> *catch* (Exception e)
> {
> *return* *null*; // No permission
> }
> }
>
> *return* m_felix.getBundleEntry(*this*, name);
> }
>
> *class Felix*
> /**
> * Implementation for Bundle.getEntry().
> **/
> *protected* URL getBundleEntry(BundleImpl bundle, String name)
> {
> *if* (bundle.getInfo().getState() == Bundle./UNINSTALLED/)
> {
> *throw* *new* IllegalStateException("The bundle is
> uninstalled.");
> }
> ==>> *return* ((ContentLoaderImpl)
> bundle.getInfo().getCurrentModule()
> .getContentLoader()).getResourceFromContent(name);
> }
>
> Here is a patch for this problem.
>
>
>
> It is basically moving the getResourceFromContent from
> ContentLoaderImpl to Felix,
> which required to modify the FindEntriesEnumeration slightly.
>
> Best regards,
>
> Olivier Gruber, Ph.D.
> Persistent & Distributed Object Platforms and Frameworks
> IBM TJ Watson Research Center
>
Re: Bug in Bundle.getEntry ?
Posted by "Richard S. Hall" <he...@ungoverned.org>.
The patch appears to not have been attached to the message...
Better yet, perhaps you could create a JIRA issue for this on the
framework component and attach the patch to it.
http://issues.apache.org/jira/browse/Felix
Thanks.
-> richard
Olivier Gruber wrote:
>
> I think I found a bug in the implementation of URL
> Bundle.getEntry(String name);
> It raises a ClassCastException when called on the system bundle since
> its content loader
> is not a ContentLoaderImpl but actually a SystemBundleContentLoader. :-(
>
> *class BundleImpl *
> * public* URL getEntry(String name)
> {
> Object sm = System./getSecurityManager/();
>
> *if* (sm != *null*)
> {
> *try*
> {
> ((SecurityManager) sm).checkPermission(*new*
> AdminPermission(*this*,
> AdminPermission./RESOURCE/));
> }
> *catch* (Exception e)
> {
> *return* *null*; // No permission
> }
> }
>
> *return* m_felix.getBundleEntry(*this*, name);
> }
>
> *class Felix*
> /**
> * Implementation for Bundle.getEntry().
> **/
> *protected* URL getBundleEntry(BundleImpl bundle, String name)
> {
> *if* (bundle.getInfo().getState() == Bundle./UNINSTALLED/)
> {
> *throw* *new* IllegalStateException("The bundle is
> uninstalled.");
> }
> ==>> *return* ((ContentLoaderImpl)
> bundle.getInfo().getCurrentModule()
> .getContentLoader()).getResourceFromContent(name);
> }
>
> Here is a patch for this problem.
>
>
>
> It is basically moving the getResourceFromContent from
> ContentLoaderImpl to Felix,
> which required to modify the FindEntriesEnumeration slightly.
>
> Best regards,
>
> Olivier Gruber, Ph.D.
> Persistent & Distributed Object Platforms and Frameworks
> IBM TJ Watson Research Center
>
Bug in Bundle.getEntry ?
Posted by Olivier Gruber <og...@us.ibm.com>.
I think I found a bug in the implementation of URL Bundle.getEntry(String
name);
It raises a ClassCastException when called on the system bundle since its
content loader
is not a ContentLoaderImpl but actually a SystemBundleContentLoader. :-(
class BundleImpl
public URL getEntry(String name)
{
Object sm = System.getSecurityManager();
if (sm != null)
{
try
{
((SecurityManager) sm).checkPermission(new
AdminPermission(this,
AdminPermission.RESOURCE));
}
catch (Exception e)
{
return null; // No permission
}
}
return m_felix.getBundleEntry(this, name);
}
class Felix
/**
* Implementation for Bundle.getEntry().
**/
protected URL getBundleEntry(BundleImpl bundle, String name)
{
if (bundle.getInfo().getState() == Bundle.UNINSTALLED)
{
throw new IllegalStateException("The bundle is uninstalled.");
}
==>> return ((ContentLoaderImpl)
bundle.getInfo().getCurrentModule()
.getContentLoader()).getResourceFromContent(name);
}
Here is a patch for this problem.
It is basically moving the getResourceFromContent from ContentLoaderImpl
to Felix,
which required to modify the FindEntriesEnumeration slightly.
Best regards,
Olivier Gruber, Ph.D.
Persistent & Distributed Object Platforms and Frameworks
IBM TJ Watson Research Center
Re: Felix problem on jamvm/NSLU2
Posted by Didier Donsez <di...@imag.fr>.
Jeff McAffer wrote:
>OSGi on a Slug is definitely feasible. Tom Watson and I demonstrated this
>with Equinox at OSGi World Congress last year. Check out the movies at
> http://www.eclipse.org/equinox/documents/
>There is plenty of room on devices like the Slug.
>
>
>
We know that !
I launch Felix on the Slug with the Felix' Jetty bundle (Http Service)
and a servlet using Felix' SCR.
but some bundles do not work well : for instance, those using iPOJO
The problem seems caused by the JamVM. I haven't test them with the J9.
Best regards
Didier
PS: your example with the MP3 server is fine ;-)
>Jeff
>
>
>
>
>"Michael E. Brown" <mi...@mindspring.com>
>08/27/2006 06:46 PM
>Please respond to
>felix-dev@incubator.apache.org
>
>
>To
>felix-dev@incubator.apache.org
>cc
>
>Subject
>Re: Felix problem on jamvm/NSLU2
>
>
>
>
>
>
>I had Oscar running with JamVM on the SLUG about a year ago using the
>links I posted earlier.
>
>Mike
>
>Niclas Hedhman wrote:
>
>
>
>>On Saturday 26 August 2006 21:29, Alex Karasulu wrote:
>>
>>
>>
>>
>>>Niclas Hedhman wrote:
>>>
>>>
>>>
>>>
>>>>On Thursday 24 August 2006 17:41, Arnaud Quiblier wrote:
>>>>
>>>>
>>>>
>>>>
>>>>>I know that Petere Kriens played with Slug too. Dont' know wheteher he
>>>>>succeeds in, but he woud be interested in people playing around Slug.
>>>>>
>>>>>Here is the post :
>>>>>http://www.aqute.biz/2005/10/osgi-on-slug.html
>>>>>
>>>>>
>>>>>
>>>>>
>>>>I happened to come across this project. Maybe it interests someone;
>>>>
>>>>https://opensource.luminis.net/confluence/display/WONKA/Home
>>>>
>>>>
>>>>
>>>>
>>>Does this run on the SLUG?
>>>
>>>
>>>
>>>
>>Don't know, but I think it would be possible to make it run on the SLUG
>>
>>
>and
>
>
>>probably smaller than devices, if one starts ripping out subsystems.
>>
>>
>>Cheers
>>Niclas
>>
>>
>>
>>
>>
>
>
>
>
--
--------------------------------------------------------------
Didier DONSEZ
INRIA/SARDES project
655, avenue de l'Europe, Montbonnot
38334 St Ismier Cedex, France
Tel : +33 4 76 61 5? ?? Fax : +33 4 76 61 52 52
GPS : lat 45°13'5.016"N, lon 05°48'26.914"E, alt 220m
Laboratoire LSR, Institut IMAG, Equipe ADELE
Universite Joseph Fourier
Bat. C, 220 rue de la Chimie, Domaine Universitaire
BP 53, 38041 Grenoble Cedex 9, France
Tel : +33 4 76 63 55 49 Fax : +33 4 76 63 55 50
GPS : lat 45°11'38.3"N, lon 05°46'14.7"E, alt 223m
mailto:Didier.Donsez@imag.fr
URL: http://www-adele.imag.fr/users/Didier.Donsez
Map: http://www-adele.imag.fr/users/Didier.Donsez/map/map.html
--------------------------------------------------------------