Hi Jim, > For example, when running on OSGi I think it would be good if an extension > could be contributed as a pure jar (no OSGi manifest entries) and then
> have the runtime somehow "dynamically" export the classes that need to > be shared (essentially performing the task of a manifest file). This > will allow us to avoid special extension packaging for different > runtimes. What about generating bundles on the fly? The Spring OSGi specification provides a virtual bundle concept which supports the creation of bundles from jar files. You can manipulate the OSGi standard headers, e.g. define the list of exported packages. Further information can be found here: http://www.springframework.org/osgi/specification Thanks Nicole -----Original Message----- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: Friday, November 10, 2006 10:48 PM To: [email protected] Subject: Re: OSGi Binding The attachment did not make it through so I checked it in to the repo here: http://svn.apache.org/viewvc/incubator/tuscany/sandbox/jim/docs/ tuscany.runtime.pdf Jim On Nov 10, 2006, at 1:38 PM, Jim Marino wrote: > > On Nov 10, 2006, at 7:53 AM, Hawkins, Joel wrote: > >> Hi guys, >> >> I'm EST (just barely). Like Nicole, I'm stuck behind a corporate >> firewall. >> Today's looking problematic for me. I'm game for either Monday (I'll >> just work from home) or possibly sometime this weekend. >> >> Some questions in the meantime: >> >> A runtime can have multiple root system composites, each isolated >> from another, and each system composite may have multiple root >> application composites. Do I (finally) have it right? > O.K this is going to stretch the limits of my ASCII art capability too > much so I'm going to attach a visual explanation (hopefully it get > through) and try a textual synopsis: > > 1. A runtime is itself a composite component > > 2. The runtime has two children, a root system composite and a root > application composite. These are isolated from one another. > > 3. The system composite may have 0..n children, some of which may be > composites. An extension is designed to be deployed as a child > composite of the root system composite (they aren't quite yet, but > that is the direction we want to go). Each system composite will have > its own classloader whose parent classlaoder will be that of the > parent composite. > > 4. Similarly, on the application side there is a root application > composite that may contain 0..n child composites. Applications would > be deployed as children of the root application composite. > > 5. Each application composite has two "sub-trees": one for child > components that are contributed by an application (e.g. other > composites or atomic components) and a special "system" tree. The > system tree generally will contain specific system services that are > scoped only to that application composite that contains them. > For example, a DataSource. If you look at the source, you will notice > that there is CompositeComponentImpl that serves as the implementation > of composite components for both the application and system trees. > Internally, it has collections that contain those two types of > children. For an child (application) composite under the root > application composite, both collections may contain children (it has > application components and system services). On the system side of the > house, when a composite is a child of the root system composite, only > the system side will contain children since there are no application > components. > > >> >> Is it sufficient for the root system composites to be isolated with >> respect to wiring (in other words, based on visibility of components >> available within the root system composite), or must they be isolated >> based on class loaders as well. I'd like to make sure that the >> fragment bundle solution is insufficient before we go off and >> re-invent fragment bundles. ;-) >> > I'd prefer not to reinvent either...I'm not sure I follow the > completely but I'll try and respond anyway ;-) Extensions loaded as > child composites of the root system composite need to be isolated in > their own classloader. In addition, they may need to share certain > extension classes with an application (e.g. Spring references > ApplicationContext internally and also allows application code to do > so). In our standalone or webapp world where no OSGi exists, we were > going to handle this by having the shared classes loaded in a > classloader that was a parent of the system composite they are > contributed as part of. Then, this parent classloader would also be > made a parent of the application composite's classloader. > > For OSGi, I was thinking we would instead rely on OSGi's import/ > export mechanism to share classes in this manner. In this case, the > shared classes would be exported and then imported by the app bundle. > One thing here was I think it would be good to maintain consistency of > extension packaging across the various hosts supported by Tuscany. For > example, when running on OSGi I think it would be good if an extension > could be contributed as a pure jar (no OSGi manifest entries) and then > have the runtime somehow "dynamically" export the classes that need to > be shared (essentially performing the task of a manifest file). This > will allow us to avoid special extension packaging for different > runtimes. > > What do you guys think? > > Jim > >> Thanks, >> Joel >> >> -----Original Message----- >> From: Wengatz, Nicole [mailto:[EMAIL PROTECTED] >> Sent: Friday, November 10, 2006 2:48 AM >> To: [email protected] >> Subject: RE: OSGi Binding >> >>> Sure. I could be available. Nicole, what Timezone are you in? I'm >>> PST, >> Joel, I believe you are CST. >> I'm CET (Germany). Having the IRC in the evening (e.g. 19:00 CET or >> later) would be fine for me. >> I assume it's anyway easier for me to attend from home (due to the >> companies firewall). >> >> Best regards >> Nicole >> -----Original Message----- >> From: Jim Marino [mailto:[EMAIL PROTECTED] >> Sent: Thursday, November 09, 2006 11:14 PM >> To: [email protected] >> Subject: Re: OSGi Binding >> >> >> On Nov 9, 2006, at 6:44 AM, Hawkins, Joel wrote: >> >>> I think an IRC might be helpful. Comments below: >> Sure. I could be available. Nicole, what Timezone are you in? I'm >> PST, Joel, I believe you are CST. >> >>> >>> -----Original Message----- >>> From: Jim Marino [mailto:[EMAIL PROTECTED] >>> Sent: Thursday, November 09, 2006 1:12 AM >>> To: [email protected] >>> Subject: Re: OSGi Binding >>> >>>> ...services. I would also like to avoid proxying the OSGi >>>> services if >>>> possible. >>> Can you define what you mean by proxying the OSGi service? Sorry if >>> I'm >>> being dense. Are you referring to support for an optimized wire? >>> >> Yes basically an optimized wire so we don't need to proxy. >> >>>> 2. The OSGi container would isolate SCA application composites >>>> according to its classloader semantics. >>> >>> >>>> Currently, Tuscany has two composite trees, an application and >>>> system >>>> tree: >>> >>> >>> Runtime >>> | >>> /\ >>> / \ >>> / Root System Composite >>> / >>> Root Application Composite >>> >>> Why only one root application composite? The code I have today >>> hosts one >>> root system composite and multiple root application composites >>> (applications pretty much correspond to bundles). >> Sorry, I'm ASCII-art challenged. The above tree could be extended to >> include multiple leaves. The root application composite can contain >> 0..n composite children, which would correspond to application >> deployed in the runtime. I just tried t simplify it here to highlight >> that there are two sides of the runtime tree. >>> The reason I did this >>> was so that I could "name" the individual applications (for external >>> management, etc). My reading of the Host API was that there was a >>> Highlander model (there can only be one) when it comes to >>> applications, >>> which makes sense in the context of a web-app deployment, but not as >>> much under OSGi. >> Yes agreed. We don't have the Highlander model here. App composites >> would be deployed as children of the root app composite (or children >> of those children). >> >>> What made me think that was that the root application >>> composite had a name. >>> >>>> The root composites may contain child composites. The system >>>> composite tree contains runtime extensions such as Axis. Each >>>> composite has its own classloader. This maintains isolation between >>>> application composites and runtime extensions.We plan on >>>> introducing >>>> a multi-parent classloader for system composites. This is arises >>>> from >>>> the need to support scenarios where application code may need to >>>> access dependencies associated with a system extension. For >>>> example, >>>> application code may need to access classes in Spring. These >>>> classes >>>> need to be shared with the application composite classloader. We >>>> were >>>> planning on loading dependencies that needed to be shared in a >>>> parent >>>> classloader of the system extension classloader. The former >>>> classloader would then also become a parent of the application >>>> classloader (which would have multiple parents). >>> >>> Comments below at the end of the extension discussion. >>> >>>> One issue is going to be reconciling this scheme with OSGi's >>>> classloading infrastructure. In relation to this, I was thinking we >>>> would want a common packaging mechanism for Tuscany extensions >>>> across >>>> host environments. For example, the Axis2 extension should not have >>>> to be repackaged or modified when deployed on Tomcat or Equinox. >>>> Application composites, however, could be bundles. I was thinking >>>> there would be one Tuscany runtime deployed to an OSGi container. >>>> This would get bootstrapped (as Joel mentioned) by a >>>> BundleActivator >>>> and would look similar to the web app launcher with one exception. >>>> Namely, while the web app launcher boots the runtime in a separate >>>> classloader, the BundleActivator would not need to do this and >>>> would >>>> instead boot Tuscany in the bundle classloader. The Tuscany runtime >>>> bundle would consequently have to export classes used by >>>> applications such as SCA API. >>> >>> >>>> Applications would be deployed as bundles as well. It would be nice >>>> if we could listen to bundles coming online and check for SCA scdl >>>> (configuration files). If one is found, we load the bundle as an >>>> application composite and stick it in the runtime application tree. >>>> The classloader for this composite would be the bundle's. The >>>> bundle >>>> itself would have to import certain SCA packages (i.e. the ones >>>> exported by the runtime bundle). >>> I think I've got this. >>> >>>> The hard part is going to be figuring out how to deal with >>>> extensions. Specifically, in the case I mentioned above where >>>> application code needs to reference certain extension classes. I >>>> would like to avoid having special packaging for Tuscany extensions >>>> when deployed to an OSGi container versus the Servlet container. >>>> So, >>>> we could deploy the same Axis2 extension to Tuscany on an OSGi >>>> container and Tuscany on a Servlet container. This would mean the >>>> runtime would have to behave slightly differently depending on this >>>> host. In this respect, perhaps what we could do is instead of >>>> creating a parent classloader to the extension and also having >>>> it as >>>> a parent to the application, we could have OSGi manage this? One >>>> way >>>> to do this would be for a particular extension to use just the >>>> bundle >>>> classloader and programmatically export packages that need to be >>>> shared (is there an OSGi api to do this, I recall a "dynamic >>>> export/ >>>> import")? One the application side, the bundle import those >>>> packages. >>> >>> OSGi has a concept known as a Bundle Fragment. A fragment is >>> packaged as >>> a separate bundle, but at runtime acts is if it were packaged >>> directly >>> as part of the host bundle. My thought was to package runtime >>> extensions >>> as fragments, and designate the sca kernel bundle as the bundle >>> host. >>> Add to that a mechanism to populate the system composite tree >>> with the >>> extensions, and you've got something that (to me) sounds very much >>> like >>> what you've described above. Application bundles could specify a >>> dependency on the sca kernel bundle, at inherit classloader >>> access to >>> all the extensions as a result. >> For system extensions, I would like to have a uniform packaging >> scheme that works across different host environments. Specifically, >> we would have a jar that is contributed to the runtime. That jar >> would be the same (e.g. Axis2 extension) and could be deployed in a >> war, to the standalone or to the OSGi container. The mechanism for >> how that jar is contributed to the runtime may vary. So, for example, >> in a war, it may go in the /lib directory. For OSGi bindle fragments, >> is there a deployment API/mechanism where I can take a plain jar >> (i.e. no OSGi manifest entries), hand it to the OSGI container and >> declare that it is a fragment (maybe it is something specific to >> Equinox)? >>> >>> What this doesn't do is allow you to hide extensions from particular >>> applications. Is this a requirement? From your diagram above (where >>> there's a single system composite tree) I'm assuming its not, but of >>> course I could be wrong :-). >>> >> Yes we need extensions to be hidden from the application. However, we >> may need some classes from the extension to be visible. For example, >> an extension may hide its StAX parser implementation but wish to >> expose an API for applications to use that is also used by some >> internal code (Spring does this with ApplicationContext). In >> standalone we would load these classes in a classloader that was the >> parent to the extension classloader. This parent would then also >> become a parent to the application composite classloader, which would >> have multiple parents. In OSGi I was thinking we would take a >> slightly different approach. Instead of creating a parent classloader >> that was shared, we would programmatically export those shared >> classes in the extension bundle. The application bundle would then >> import them. >>>> Do you guys think this makes sense? I have some skeletal code >>>> checked >>>> into the OSGi and Equinox projects. >>> >>>> Also, I would like to try and get any code checked into the trunk >>>> since this will make things easier. Joel, when you get things >>>> synced >>>> back up submit a patch and I can apply it. Similarly, Nicole, if >>>> you >>>> have code that could benefit from being checked in, let me know. >>> >>> I'll get back to the patch. There's some code in there I need to >>> remove >>> - it was placed in as part of a demo I did at EclipseWorld that >>> showed a >>> sample WSDM integration using a management annotation. Sorry for the >>> delay on that - swarms of distractions here. >>> >> NP I'm the same way. If possible it would be great to see/hear about >> what you did. >>> >>> The contents of this e-mail are intended for the named addressee >>> only. It contains information that may be confidential. Unless you >>> are the named addressee or an authorized designee, you may not copy >>> or use it, or disclose it to anyone else. If you received it in >>> error please notify us immediately and then destroy it. >>> >>> -------------------------------------------------------------------- >>> - >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> The contents of this e-mail are intended for the named addressee >> only. It contains information that may be confidential. Unless you >> are the named addressee or an authorized designee, you may not >> copy or use it, or disclose it to anyone else. If you received it >> in error please notify us immediately and then destroy it. >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
