Tuesday 8 PST works for me as well.
Cheers,
Joel
-----Original Message-----
From: Wengatz, Nicole [mailto:[EMAIL PROTECTED]
Sent: Saturday, November 11, 2006 2:01 PM
To: [email protected]
Subject: RE: OSGi Binding
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: [email protected]
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: [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]
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]
