Re: Bundle in RESOLVED state even after a class has been loaded by that bundle

On 12/01/2008, Richard S. Hall <[EMAIL PROTECTED]> wrote: > > Sahoo wrote: > > Richard S. Hall wrote: > >> > >> In R4.1, class loading is currently the only defined trigger that > >> causes deferred activation. > > It's exactly this choice of trigger that had confused me earlier. I am > > not sure

Re: OBR best practice

Ok, Richard; Thank's a lot for your help. I think I have now a clear understanding about the OBR. As you suggested, may be the best thing to do is to make a sort of "application installer" on top of the BundleRepository service. Regards; /Pierre. Richard S. Hall wrote: Pierre De Rop wrote:

Re: Can Bundle.loadClass() load non-exported class

Yes, this gives access to everything, which is why you need permission to do this if security is enabled. Generally speaking, bundles should never need to directly load classes from another bundle, since the whole point of the OSGi framework is to raise this level of abstraction. However, somet

Can Bundle.loadClass() load non-exported class

It looks like Bundle.loadClass() is able to load a class even when the corresponding package is not exported by the bundle. Is this the right behavior? Thanks, Sahoo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional c

Re: Bundle in RESOLVED state even after a class has been loaded by that bundle

Sahoo wrote: Richard S. Hall wrote: In R4.1, class loading is currently the only defined trigger that causes deferred activation. It's exactly this choice of trigger that had confused me earlier. I am not sure why Bundle.loadClass was chosen as the trigger for deferred activation. Any way, t

Re: Bundle in RESOLVED state even after a class has been loaded by that bundle

Richard S. Hall wrote: In R4.1, class loading is currently the only defined trigger that causes deferred activation. It's exactly this choice of trigger that had confused me earlier. I am not sure why Bundle.loadClass was chosen as the trigger for deferred activation. Any way, that does not s

Re: Bundle in RESOLVED state even after a class has been loaded by that bundle

Sahoo wrote: Hi Angelo, I am confused. Please help me understand something here. If what you said were the intention of the spec, why does the spec require Bundle.loadClass() to cause the corresponding bundle to go to ACTIVE state when the bundle uses LAZY activation policy [1]? Seems like LA

Re: OBR best practice

Pierre De Rop wrote: I think I understand what is going on: In the OBR, I have: * B1.jar (with "Import-Package: com.b2" and Import-Service: B2") -> installed from OBR * B2.jar (with "Export-Package: com.b2") -> installed from OBR * B2Impl.jar (with "Export-Service: B2") -> install

Re: Bundle in RESOLVED state even after a class has been loaded by that bundle

Hi Angelo, I am confused. Please help me understand something here. If what you said were the intention of the spec, why does the spec require Bundle.loadClass() to cause the corresponding bundle to go to ACTIVE state when the bundle uses LAZY activation policy [1]? Seems like LAZY is more ea

Re: OBR best practice

Hi, Am Dienstag, den 08.01.2008, 14:25 -0500 schrieb Richard S. Hall: > It sounds like what you want is some way to install "applications". OBR > was not intended to support applications...I figured this would be a > layer above OBR. Such a layer above OBR could be an extension supporting the d

Re: OBR best practice

Hi Pierre, Am Freitag, den 11.01.2008, 00:03 +0100 schrieb Pierre De Rop: > Richard; > > I think I understand what is going on: > In the OBR, I have: > > * B1.jar (with "Import-Package: com.b2" and Import-Service: B2") -> > installed from OBR > * B2.jar (with "Export-Package: com.