Hi, Asier Aranbarri Beldarrain schrieb: > > > /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/ > > Hi Felix: > > What I'm talking about is that I have my own java classes, just like this: > > ToOsgi (Java Project) > ----> src > --------->toosgiPackage > ---------------->javaClass1.java > ---------------->javaClass2.java > ---------------->javaClass3.java > ---------------->interface1.java > > What I want is to "insert" "toosgiPackage" into a bundle. I don't know > if I only have to start a new Plug-in project, delete the activator.java > and just copy those classes and the interface in the bundle's SRC or the > ,mechanism is more complicated.
Besides putting the sources into you project, you also have to export the them. If you are talking about "plugin-in project" I assume you are using Eclipse. There you can open the prepared MANIFEST.MF file and go to the Runtime page and list the package in the "Exported Packages" list. If you need more information regarding the Eclipse Bundle support, you might want to ask in the respective Eclipse forums. Regards Felix > > What I want is to have an independent bundle which gives the services > implemented in those classes. > > 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: Re: osgi-dev Digest, Vol 37, Issue 20 (Felix Meschberger) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 30 Nov 2009 10:00:21 +0100 > From: Felix Meschberger <[email protected] <mailto:[email protected]>> > Subject: Re: [osgi-dev] Re: osgi-dev Digest, Vol 37, Issue 20 > 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 > > 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]> > > <mailto:[email protected] > <mailto:[email protected]>>> > > > > Send osgi-dev mailing list submissions to > > [email protected] <mailto:[email protected]> > <mailto:[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]> > > <mailto:[email protected] > <mailto:[email protected]>> > > > > You can reach the person managing the list at > > [email protected] > <mailto:[email protected]> > > <mailto:[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]> <mailto:[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]> > > <mailto:[email protected] <mailto:[email protected]>>> > > Cc: OSGi Developer Mail List <[email protected] > <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>>, > > [email protected] > <mailto:[email protected]> > > <mailto:[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> > > > > <mailto: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]> <mailto:[email protected] > <mailto:[email protected]>>> > > To: > > OSGi Developer Mail List <[email protected] > <mailto:[email protected]> > > <mailto:[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]> > <mailto:[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]> > > <mailto:[email protected] <mailto:[email protected]>>> > > > To: OSGi Developer Mail List > <[email protected] <mailto:[email protected]> > > <mailto:[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]> > > <mailto:[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]> > <mailto:[email protected] <mailto:[email protected]>> > > > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > _______________________________________________ > > > OSGi Developer Mail List > > > [email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > > > https://mail.osgi.org/mailman/listinfo/osgi-dev > > _______________________________________________ > > OSGi Developer Mail List > > [email protected] <mailto:[email protected]> > <mailto:[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]> <mailto:[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]> > > <mailto:[email protected] <mailto:[email protected]>>> > > Message-ID: <[email protected] > <mailto:[email protected]> <mailto:[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]> > > <mailto:[email protected] <mailto:[email protected]>>> > > > To: OSGi Developer Mail List <[email protected] > <mailto:[email protected]> > > <mailto:[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]> > > <mailto:[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]> > > <mailto:[email protected] <mailto:[email protected]>>> > > >> To: OSGi Developer Mail List > > <[email protected] <mailto:[email protected]> > <mailto:[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]> > > <mailto:[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]> > <mailto:[email protected] <mailto:[email protected]>> > > >> https://mail.osgi.org/mailman/listinfo/osgi-dev > > >> > > >> > > >> > > >> > > > ------------------------------------------------------------------------ > > >> > > >> _______________________________________________ > > >> OSGi Developer Mail List > > >> [email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > > >> https://mail.osgi.org/mailman/listinfo/osgi-dev > > > _______________________________________________ > > > OSGi Developer Mail List > > > [email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > > > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > _______________________________________________ > > > OSGi Developer Mail List > > > [email protected] <mailto:[email protected]> > <mailto:[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]> > <mailto:[email protected] <mailto:[email protected]>>> > > Subject: [osgi-dev] Class sharing with OSGi ClassLoading framework > > To: [email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > > Message-ID: > > > <[email protected] > <mailto:[email protected]> > > > <mailto:[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]> > <mailto:[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] <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 > > End of osgi-dev Digest, Vol 37, Issue 22 > **************************************** > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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
