Good morning all:

I have an issue with OSGi platform;

I need to "insert" a Java package (5 classes and 1 interface) into a new
OSGi bundle, so that it can implement those services in wherever machine you
run the bundle(sorry for my english).

I don't really know how it must be done and any help or link to any tutorial
would be very appreciated.

Thank you very much,

Asier.

2009/11/30 <[email protected]>

> Send osgi-dev mailing list submissions to
>        [email protected]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://mail.osgi.org/mailman/listinfo/osgi-dev
> or, via email, send a message with subject or body 'help' to
>        [email protected]
>
> You can reach the person managing the list at
>        [email protected]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of osgi-dev digest..."
>
>
> Today's Topics:
>
>   1. Re: [DS] Question regarding CompoinentInstance for service
>      factory components (Simon J Archer)
>   2. Re: [DS] Question regarding CompoinentInstance for service
>      factory components (Felix Meschberger)
>   3. Class sharing with OSGi ClassLoading framework (Vinoth)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 30 Nov 2009 00:12:34 -0500
> From: Simon J Archer <[email protected]>
> Subject: Re: [osgi-dev] [DS] Question regarding CompoinentInstance for
>        service factory components
> To: OSGi Developer Mail List <[email protected]>
> Cc: OSGi Developer Mail List <[email protected]>,
>        [email protected]
> Message-ID:
>        <
> ofad846032.831b6d23-on8525767e.00199740-8525767e.001c9...@us.ibm.com>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi Felix
>
> Sorry for the delay in responding...
>
> >> Yet, here is the problem: The Service is not unregistered from the
> >> ServiceRegistry, thus Bundle B1 is not informed about the instance Cb1
> >> being deactivated.
>
> My understanding is that when a ComponentInstance has its dispose() method
> called the component's provided services must be unregistered from the
> Service Registry.  So, if you are seeing registered service from a
> disposed component then that would be a bug in the DS implementation that
> you are using. I just tested this scenario on Equinox and it worked for
> me.  Which are you using?
>
> I checked the spec and here's what I found. I believe that this backs up
> what I am saying. I have marked the most important bits in bold, so I hope
> that the formatting is not lost.
>
> 112.2.4 Factory Component
> ...
> New configurations of the component can be created and activated by
> calling the newInstance method on this Component Factory service. The
> newInstance(Dictionary) method has a Dictionary object as argument. This
> Dictionary object is merged with the component properties as described in
> Component Properties on page 326. If the component specifies a service,
> then the service is registered after the created component configuration
> is satisfied with the component properties. Then the component
> configuration is activated.
> ...
> A new service will be registered each time a new component configuration
> is created and activated with the newInstance method. This allows a bundle
> other than the one creating the component configuration to utilize the
> service. If the component configuration is deactivated, the service must
> be unregistered.
> ...
> 112.12.6 public interface ComponentInstance
> ...
> public void dispose( )
> Dispose of the component configuration for this component instance. The
> component configuration will be deactivated. If the component
> configuration has already been deactivated, this method does nothing.
>
> I hope this helps,
>
> Simon
>
>
>
> From:
> Felix Meschberger <[email protected]>
> To:
> OSGi Developer Mail List <[email protected]>
> Date:
> 11/27/2009 02:59 PM
> Subject:
> Re: [osgi-dev] [DS] Question regarding CompoinentInstance for service
> factory components
> Sent by:
> [email protected]
>
>
>
> Hi,
>
> Thanks for your response.
>
> Yet I am not sure, whether I was clear enough in my question. Let me
> rephrase it with an example:
>
> Consider a service factory Component C. Bundles B1 and B2 have acquired
> the service, this they get object instances (configurations) Cb1 and
> Cb2. These two instances are backed a ComponentInstance Cib1 and Cib2.
>
> Question is: What happens when dispose() is called on ComponentInstance
> Cib1 ?
>
> Option 1 would be, that Component C is disposed off and thus instances
> Cb1 and Cb2.
>
> Option 2 would be, that only instance Cb1 is disposed off. If I
> understand the spec correctly, this would be the intended way of the spec.
>
> Yet, here is the problem: The Service is not unregistered from the
> ServiceRegistry, thus Bundle B1 is not informed about the instance Cb1
> being deactivated.
>
> We can say: no problem, because only Bundle B1 can get at the
> ComponentInstance Cib1 and thus can take precautions on this situation.
>
> Does this sound right an/or understandable ?
>
> Thanks and Regards
> Felix
>
> Simon J Archer schrieb:
> >
> >>From reading the spec the second option seems correct.
> >
> > I agree that (2) is the correct behavior.  It would never occur to me to
> > wish for (1).
> >
> >>>But thinking this through in my understanding this means
> >>>to deactivate an object which has been distributed to
> >>>consumers by the service registry without informing the
> >>>service registry about that fact.
> >
> > When a ComponentInstance is disposed any services provided by the DS
> > component are unregistered and removed from the OSGi service registry
> > before the component is deactivated. Of course, the unregistration of a
> > service will likely affect other DS components, and so on up the
> > dependency tree.
> >
> >
> > From:                  Felix Meschberger <[email protected]>
> > To:            OSGi Developer Mail List <[email protected]>
> > Date:                  11/23/2009 10:19 AM
> > Subject:               [osgi-dev] [DS] Question regarding
> CompoinentInstance for
> > service        factory components
> > Sent by:               [email protected]
> >
> >
> > ------------------------------------------------------------------------
> >
> >
> >
> > Hi all,
> >
> > While discussing the development of a Management/Administrative API for
> > DS we came across a problem with respect to the
> > ComponentInstance.dispose() method when applied to an instance of a
> > service factory component.
> >
> > There are basically two options:
> >
> > (1) dispose() applies to the component as a whole. That is the
> >     service is unregistered and all component instances are
> >     disposed off.
> >
> > (2) dispose() applies only to the component instance (object) on whose
> >     ComponentInstance object the method has been called.
> >
> >>From reading the spec the second option seems correct. But thinking this
> > through in my understanding this means to deactivate an object which
> > has been distributed to consumers by the service registry without
> > informing the service registry about that fact.
> >
> > Thanks for any help.
> >
> > Regards
> > Felix
> >
> > _______________________________________________
> > OSGi Developer Mail List
> > [email protected]
> > https://mail.osgi.org/mailman/listinfo/osgi-dev
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > OSGi Developer Mail List
> > [email protected]
> > https://mail.osgi.org/mailman/listinfo/osgi-dev
> _______________________________________________
> OSGi Developer Mail List
> [email protected]
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://mail.osgi.org/pipermail/osgi-dev/attachments/20091130/96d8b8ab/attachment-0001.html
>
> ------------------------------
>
> Message: 2
> Date: Mon, 30 Nov 2009 08:54:35 +0100
> From: Felix Meschberger <[email protected]>
> Subject: Re: [osgi-dev] [DS] Question regarding CompoinentInstance for
>        service factory components
> To: OSGi Developer Mail List <[email protected]>
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=UTF-8
>
> Hi Simon,
>
> Simon J Archer schrieb:
> > Sorry for the delay in responding...
>
> No problem... Thanks alot for keeping with me ;-)
>
> >
> >>> Yet, here is the problem: The Service is not unregistered from the
> >>> ServiceRegistry, thus Bundle B1 is not informed about the instance Cb1
> >>> being deactivated.
> >
> > My understanding is that when a ComponentInstance has its dispose()
> > method called the component's provided services must be unregistered
> > from the Service Registry.  So, if you are seeing registered service
> > from a disposed component then *that would be a bug* in the DS
> > implementation that you are using. I just tested this scenario on
> > Equinox and it worked for me.  Which are you using?
> >
> > I checked the spec and here's what I found. I believe that this backs up
> > what I am saying. I have marked the most important bits in *bold*, so I
> > hope that the formatting is not lost.
> >
> > 112.2.4 Factory Component
>
> Ah ! I am speaking about: 112.2.3 Delayed Component with the
> servicefactory attribute set to true.
>
> It says in 112.4.6, Service Element:
>
>     If servicefactory is set to true, a different component
>     configuration is created, activated and its component instance
>     returned as the service object for each distinct bundle that
>     requests the service. Each of these component configurations has
>     the same component properties.
>
> This is where the question stems from: For each bundle B1, B2, ...
> requesting the service a different componnent configuration must be
> created and its component instance returned.
>
> Taking this along the lines of the ComponentInstance described below
> would mean that calling the dispose method just disposes off a single
> instance but not the service registration. Thus tearing off a service
> instance from below the service registry's feet because the service is
> not unregistered.
>
> The Apache Felix implementation (which I am using and maintaining)
> currently completely disposes off the Component if the dispose method is
> called - that is the service is actually unregistered and all service
> instances ever created by the service factory are deactivated/destroyed.
>
> The Equinox implementation (according to Stoyan Boshev) just disposes
> off the single component instance (aka object) thus removing the service
> object without the ServiceRegistry knowing about it. That is the service
> as such is not unregistered.
>
>  * Which way is intended by the spec ?
>  * Is the ComponentInstance intended to only be used for 112.2.5 Factory
>   Components ?
>
> Regards
> Felix
>
> > ...
> > New configurations of the component can be created and activated by
> > calling the newInstance method on this Component Factory service. The
> > newInstance(Dictionary) method has a Dictionary object as argument. This
> > Dictionary object is merged with the component properties as described
> > in Component Properties on page 326. *If the component specifies a
> > service, then the service is registered after the created component
> > configuration is satisfied with the component properties.* Then the
> > component configuration is activated.
> > ...
> > A new service will be registered each time a new component configuration
> > is created and activated with the newInstance method. This allows a
> > bundle other than the one creating the component configuration to
> > utilize the service. *If the component configuration is deactivated, the
> > service must be unregistered.*
> > ...
> > 112.12.6 public interface ComponentInstance
> > ...
> > *public void dispose( )*
> > Dispose of the component configuration for this component instance. *The
> > component configuration will be deactivated.* If the component
> > configuration has already been deactivated, this method does nothing.
> >
> > I hope this helps,
> >
> > Simon
> >
> >
> > From:         Felix Meschberger <[email protected]>
> > To:   OSGi Developer Mail List <[email protected]>
> > Date:         11/27/2009 02:59 PM
> > Subject:      Re: [osgi-dev] [DS] Question regarding CompoinentInstance
> for
> > service        factory components
> > Sent by:      [email protected]
> >
> >
> > ------------------------------------------------------------------------
> >
> >
> >
> > Hi,
> >
> > Thanks for your response.
> >
> > Yet I am not sure, whether I was clear enough in my question. Let me
> > rephrase it with an example:
> >
> > Consider a service factory Component C. Bundles B1 and B2 have acquired
> > the service, this they get object instances (configurations) Cb1 and
> > Cb2. These two instances are backed a ComponentInstance Cib1 and Cib2.
> >
> > Question is: What happens when dispose() is called on ComponentInstance
> > Cib1 ?
> >
> > Option 1 would be, that Component C is disposed off and thus instances
> > Cb1 and Cb2.
> >
> > Option 2 would be, that only instance Cb1 is disposed off. If I
> > understand the spec correctly, this would be the intended way of the
> spec.
> >
> > Yet, here is the problem: The Service is not unregistered from the
> > ServiceRegistry, thus Bundle B1 is not informed about the instance Cb1
> > being deactivated.
> >
> > We can say: no problem, because only Bundle B1 can get at the
> > ComponentInstance Cib1 and thus can take precautions on this situation.
> >
> > Does this sound right an/or understandable ?
> >
> > Thanks and Regards
> > Felix
> >
> > Simon J Archer schrieb:
> >>
> >>>From reading the spec the second option seems correct.
> >>
> >> I agree that (2) is the correct behavior.  It would never occur to me to
> >> wish for (1).
> >>
> >>>>But thinking this through in my understanding this means
> >>>>to deactivate an object which has been distributed to
> >>>>consumers by the service registry without informing the
> >>>>service registry about that fact.
> >>
> >> When a ComponentInstance is disposed any services provided by the DS
> >> component are unregistered and removed from the OSGi service registry
> >> before the component is deactivated. Of course, the unregistration of a
> >> service will likely affect other DS components, and so on up the
> >> dependency tree.
> >>
> >>
> >> From:                  Felix Meschberger <[email protected]>
> >> To:                  OSGi Developer Mail List <[email protected]>
> >> Date:                  11/23/2009 10:19 AM
> >> Subject:                  [osgi-dev] [DS] Question regarding
> > CompoinentInstance for
> >> service        factory components
> >> Sent by:                  [email protected]
> >>
> >>
> >> ------------------------------------------------------------------------
> >>
> >>
> >>
> >> Hi all,
> >>
> >> While discussing the development of a Management/Administrative API for
> >> DS we came across a problem with respect to the
> >> ComponentInstance.dispose() method when applied to an instance of a
> >> service factory component.
> >>
> >> There are basically two options:
> >>
> >> (1) dispose() applies to the component as a whole. That is the
> >>     service is unregistered and all component instances are
> >>     disposed off.
> >>
> >> (2) dispose() applies only to the component instance (object) on whose
> >>     ComponentInstance object the method has been called.
> >>
> >>>From reading the spec the second option seems correct. But thinking this
> >> through in my understanding this means to deactivate an object which
> >> has been distributed to consumers by the service registry without
> >> informing the service registry about that fact.
> >>
> >> Thanks for any help.
> >>
> >> Regards
> >> Felix
> >>
> >> _______________________________________________
> >> OSGi Developer Mail List
> >> [email protected]
> >> https://mail.osgi.org/mailman/listinfo/osgi-dev
> >>
> >>
> >>
> >> ------------------------------------------------------------------------
> >>
> >> _______________________________________________
> >> OSGi Developer Mail List
> >> [email protected]
> >> https://mail.osgi.org/mailman/listinfo/osgi-dev
> > _______________________________________________
> > OSGi Developer Mail List
> > [email protected]
> > https://mail.osgi.org/mailman/listinfo/osgi-dev
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > OSGi Developer Mail List
> > [email protected]
> > https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 30 Nov 2009 14:08:28 +0530
> From: Vinoth <[email protected]>
> Subject: [osgi-dev] Class sharing with OSGi ClassLoading framework
> To: [email protected]
> Message-ID:
>        <[email protected]>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi,
>
> In the following link (
>
> http://publib.boulder.ibm.com/infocenter/realtime/v2r0/index.jsp?topic=/com.ibm.softrt.aix64.doc/diag/tools/shared_classes_pd.html
> ),
> it says:
>
> "Eclipse releases after 3.0 use the OSGi ClassLoading framework, which
> cannot automatically share classes. A Class Sharing adapter has been
> written
> specifically for use with OSGi, which allows OSGi classloaders to access
> the
> class cache."
>
> Is it possible to get more details on "Class Sharing adapter" and how to
> use
> that adapter?
> Is there any documentation/ references available?
>
> Or else suggest me if there is any way to share the osgi class loader
> (org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader) to non-osgi
> world. (i.e., when I access the bundle context to invoke the plug-in
> functions via EclipseStarter.)
>
> --
> Thanks,
> Vinoth
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://mail.osgi.org/pipermail/osgi-dev/attachments/20091130/9c25b200/attachment.html
>
> ------------------------------
>
> _______________________________________________
> OSGi Developer Mail List
> [email protected]
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
> End of osgi-dev Digest, Vol 37, Issue 20
> ****************************************
>
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev

Reply via email to