Hi Asier Aranbarri Beldarrain schrieb: > 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).
What exact "Java" package are we talking about ? If it is any package except some package in the java.* package space, you just include this in a bundle and Export-Package the package (list the package in the Export-Package header). If the package is from the java.* package space, you have to upgrade the Java VM, since IIUIC the OSGi spec requires packages from java.* to be loaded through the boot class loader. HTH Regards Felix > > 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] > <mailto:[email protected]>> > > Send osgi-dev mailing list submissions to > [email protected] <mailto:[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] > <mailto:[email protected]> > > You can reach the person managing the list at > [email protected] > <mailto:[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] <mailto:[email protected]>> > Subject: Re: [osgi-dev] [DS] Question regarding CompoinentInstance for > service factory components > To: OSGi Developer Mail List <[email protected] > <mailto:[email protected]>> > Cc: OSGi Developer Mail List <[email protected] > <mailto:[email protected]>>, > [email protected] > <mailto:[email protected]> > Message-ID: > > <ofad846032.831b6d23-on8525767e.00199740-8525767e.001c9...@us.ibm.com > > <mailto: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] <mailto:[email protected]>> > To: > OSGi Developer Mail List <[email protected] > <mailto:[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] <mailto:[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] > <mailto:[email protected]>> > > To: OSGi Developer Mail List <[email protected] > <mailto:[email protected]>> > > Date: 11/23/2009 10:19 AM > > Subject: [osgi-dev] [DS] Question regarding > CompoinentInstance for > > service factory components > > Sent by: [email protected] > <mailto:[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] <mailto:[email protected]> > > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > OSGi Developer Mail List > > [email protected] <mailto:[email protected]> > > https://mail.osgi.org/mailman/listinfo/osgi-dev > _______________________________________________ > OSGi Developer Mail List > [email protected] <mailto:[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] <mailto:[email protected]>> > Subject: Re: [osgi-dev] [DS] Question regarding CompoinentInstance for > service factory components > To: OSGi Developer Mail List <[email protected] > <mailto:[email protected]>> > Message-ID: <[email protected] <mailto:[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] > <mailto:[email protected]>> > > To: OSGi Developer Mail List <[email protected] > <mailto:[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] > <mailto:[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] > <mailto:[email protected]>> > >> To: OSGi Developer Mail List > <[email protected] <mailto:[email protected]>> > >> Date: 11/23/2009 10:19 AM > >> Subject: [osgi-dev] [DS] Question regarding > > CompoinentInstance for > >> service factory components > >> Sent by: [email protected] > <mailto:[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] <mailto:[email protected]> > >> https://mail.osgi.org/mailman/listinfo/osgi-dev > >> > >> > >> > >> > ------------------------------------------------------------------------ > >> > >> _______________________________________________ > >> OSGi Developer Mail List > >> [email protected] <mailto:[email protected]> > >> https://mail.osgi.org/mailman/listinfo/osgi-dev > > _______________________________________________ > > OSGi Developer Mail List > > [email protected] <mailto:[email protected]> > > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > OSGi Developer Mail List > > [email protected] <mailto:[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] <mailto:[email protected]>> > Subject: [osgi-dev] Class sharing with OSGi ClassLoading framework > To: [email protected] <mailto:[email protected]> > Message-ID: > <[email protected] > <mailto:[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] <mailto:[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 _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
