/2006 11:19 AM
Please respond to
felix-dev@incubator.apache.org
To
felix-dev@incubator.apache.org
cc
Subject
Re: bundle.getResources behavior
Yes, I agree. This definitely turned out to be a spring-osgi issue all
around, although the ClassLoader.getResources() being final could also
cause
Resources method. Then at runtime pick the correct
>> implementation
>> >> >> of the bundle classloader depending on the level of the EE. But
>> this
>> >> >> would force me to compile the core framework against J2SE 1.5.
>> >&g
e
bundle
>> >> classloader if it is installed and resolved. I would make that
>> >> fragment bundle have a required EE of J2SE 1.5 so it could not be
>> >> installed on an older VM.
>> >>
>> >> Tom
>> >>
>> >>
>&
in a
>> >> framework fragment, then runtime can load that version of the bundle
>> >> classloader if it is installed and resolved. I would make that
>> >> fragment bundle have a required EE of J2SE 1.5 so it could not be
>> >> installed on an older V
gt;
>>
>> "Richard S. Hall" <[EMAIL PROTECTED]> 12/14/2006 07:35 AM
>> Please respond to
>> felix-dev@incubator.apache.org
>>
>>
>> To
>> felix-dev@incubator.apache.org
>> cc
>>
>> Subject
>> Re: bundle.getResources
bator.apache.org
To
felix-dev@incubator.apache.org
cc
Subject
Re: bundle.getResources behavior
Well, thats easy enough! I looked but couldn't find that. Thanks!
Chris
On 12/14/06, Marcel Offermans <[EMAIL PROTECTED]> wrote:
>
> The system bundle has an ID of 0 (zero). Th
Well, thats easy enough! I looked but couldn't find that. Thanks!
Chris
On 12/14/06, Marcel Offermans <[EMAIL PROTECTED]> wrote:
The system bundle has an ID of 0 (zero). This is defined in the spec.
On Dec 14, 2006, at 16:59 , Chris Custine wrote:
> When you do context.getBundles(), is the
The system bundle has an ID of 0 (zero). This is defined in the spec.
On Dec 14, 2006, at 16:59 , Chris Custine wrote:
When you do context.getBundles(), is there any way to distinguish
the System
bundle from other bundles (not Felix specific, hopefully OSGi spec)?
Something like a marker or f
k this extra class (compiled against J2SE 1.5) in a
> >> >> framework fragment, then runtime can load that version of the
> bundle
> >> >> classloader if it is installed and resolved. I would make that
> >> >> fragment bundle have a required EE of J2SE 1.5 s
ra class (compiled against J2SE 1.5) in a
>> >> framework fragment, then runtime can load that version of the bundle
>> >> classloader if it is installed and resolved. I would make that
>> >> fragment bundle have a required EE of J2SE 1.5 so it could not be
>>
e
>> installed on an older VM.
>>
>> Tom
>>
>>
>>
>>
>> "Richard S. Hall" <[EMAIL PROTECTED]> 12/14/2006 07:35 AM
>> Please respond to
>> felix-dev@incubator.apache.org
>>
>>
>> To
>> felix-dev@incub
On second thought, as BJ Hargrave pointed out to me, if this is going
through Bundle.getResources() then we should be able to avoid it...I
will look into it a little bit and see if I can figure anything out.
-> richard
Chris Custine wrote:
My understanding of the OSGi spec is that Bundle.getRe
that
>> fragment bundle have a required EE of J2SE 1.5 so it could not be
>> installed on an older VM.
>>
>> Tom
>>
>>
>>
>>
>> "Richard S. Hall" <[EMAIL PROTECTED]> 12/14/2006 07:35 AM
>> Please respond to
o it could not be
installed on an older VM.
Tom
"Richard S. Hall" <[EMAIL PROTECTED]> 12/14/2006 07:35 AM
Please respond to
felix-dev@incubator.apache.org
To
felix-dev@incubator.apache.org
cc
Subject
Re: bundle.getResources behavior
Thomas Watson wrote:
This i
]>
12/14/2006 07:35 AM
Please respond to
felix-dev@incubator.apache.org
To
felix-dev@incubator.apache.org
cc
Subject
Re: bundle.getResources behavior
Thomas Watson wrote:
This is probably because the ClassLoader.getResources method is final on
J2SE 1.4 and earlier. I
gment bundle have a required EE of J2SE 1.5 so it could not be
installed on an older VM.
Tom
"Richard S. Hall" <[EMAIL PROTECTED]>
12/14/2006 07:35 AM
Please respond to
felix-dev@incubator.apache.org
To
felix-dev@incubator.apache.org
cc
Subject
Re: bundle.getResources behavio
Thomas Watson wrote:
This is probably because the ClassLoader.getResources method is final on
J2SE 1.4 and earlier. In J2SE 1.5 they removed the 'final' from this
method. This makes it impossible to implement a "correct" bundle
classloader on J2SE 1.4 and earlier WRT ClassLoader.getResources.
This is probably because the ClassLoader.getResources method is final on
J2SE 1.4 and earlier. In J2SE 1.5 they removed the 'final' from this
method. This makes it impossible to implement a "correct" bundle
classloader on J2SE 1.4 and earlier WRT ClassLoader.getResources. The
implementation
rms 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" <[EMAIL PROTECTED]>
09/22/2006 04:15 PM
Please respond to
felix-dev@incubator.apache.org
To
felix-dev@in
first the idea is not absurd, then there is no hope for it."
Albert Einstein
"Richard S. Hall" <[EMAIL PROTECTED]>
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, w
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 consid
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
enumerat
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.
T
23 matches
Mail list logo
