Tuesday 8 PST works for me. Thanks Nicole
-----Original Message----- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: Friday, November 10, 2006 8:05 PM To: tuscany-dev@ws.apache.org Subject: Re: OSGi Binding Monday early morning is bad for me (I have a meeting starting early). Could we do Tuesday 8PST? I have a similar problem with corporate firewalls. One way I found around this is to tunnel IRC traffic through an SSH connection to an external shell account (Joel, you may be able to use your Apache shell account). I use OS X TunnelManager to automate this and I believe Putty on Windows will work. Of course, I'm not telling anyone to break corporate security policy... :-) If this time doesn't work for people let me know some alternatives that would work. I'll respond to the questions below separately. Jim 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? > > 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. ;-) > > Thanks, > Joel > > -----Original Message----- > From: Wengatz, Nicole [mailto:[EMAIL PROTECTED] > Sent: Friday, November 10, 2006 2:48 AM > To: tuscany-dev@ws.apache.org > 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: tuscany-dev@ws.apache.org > 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: tuscany-dev@ws.apache.org >> 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]
