|
| Re: Multiple ExtensionRegistries in OSGi [message #87737 is a reply to message #87630] |
Mon, 07 May 2007 03:17  |
 Simon Kaegi
Messages: 381
Registered: July 2009 |
Senior Member |
|
|
Hi Michael,
I found this to be an interesting read and I definitely agree that the
issues around application isolation are critical in the J2EE world. At the
same time sharing capabilities/resources is critical too.
One approach for using OSGi to build your server infrastructe while still
supporting strong isolation and controlled resource sharing is to embed
another instance of OSGi/Equinox for each applications. This approach is
used by the Servletbridge, so for example when running the bridge on
Websphere 6.1 you're running Equinox embedded in Equinox. You can also share
resources from the JEE container with a technique that uses System bundle
fragments to expose select java packages. The Servletbridge is primariliy
geared for servlet applications so by default only exposes the Servlet API
using this technique however similar approaches could be used to support
EJB, JMS, or potentially shared modelled resources.
..
Within a single framework there still might be need for scoped
services/extensions. Opt-in scoping can be done with service properties, but
for stronger scoping guarantees short of full framework isolation as above
I'm not sure what to suggest. Security might provide a workable approach
here however it feels to me like a bit of a misuse. Perhaps others know if
there's anything being done for either scoped services or similarly
extension registry scoping?
-Simon
"Michael Kanaley" <mkanaley@tibco.com> wrote in message
news:f1fdvt$l36$1@build.eclipse.org...
> Hello,
> I was just wondering the future plans for Eclipse extensions/extension
> points (and EMF) in a OSGi environment used as a J2EE-like container.
>
> The power of J2EE lies in the ability to deploy multiple independent
> applications - each in it's own sandbox - into the same JVM.
> This improves utilization of machine resources and performance.
> Sharing across applications is done thru very strict interfaces (JCA) or
> putting code into a common shared classloader (requiring restart).
> Along comes OSGi and opens these boundaries but, depending on how it is
> used, can also eliminate the "sandbox" notion and increase instability of
> production systems by simply deploying a new application.
>
> Currently any bundle that uses an extension/extension point (like a bundle
> for an emf model that declares a genmodel location) MUST declare
> singleton=true in the manifest.
> This prevents multiple versions of the bundle to run in the same OSGi
> runtime.
> I believe the reason for this is a static ExtensionRegistry.
>
> Although OSGi will still let you update this single bundle, it is hard to
> imagine OSGi becoming a J2EE replacement since the notion of a "sandbox"
> is
> missing.
> An application deployed in an OSGi-compatible container could have
> one of its singleton dependencies "updated" by another deployed
> application
> which is unacceptable.
> Also, each deployed application should have it's own ExtensionRegistry -
> my application should not have to weed out extensions that are not in the
> dependency set of my application.
>
> The easiest way to work around this is to "embed" the singleton bundles as
> JAR files (like a WAR holding JAR files in web-inf/lib) in the deployed
> bundle but this defeats the purpose of moving to OSGi in the first place.
>
> Perhaps the extension registry need not be just a static (although that
> will
> exist too for existing applications and ones that don't want to
> create/lookup their extension registry).
> It could be actually stored as an OSGi service (locatable by the bundle
> that
> creates it).
> It would contain the extensions for the bundle creating it and all of its
> dependent bundles and bundles providing imported packages.
>
> Perhaps someone else has other ways of providing this type of
> functionality?
> Are there any plans to support something like this?
> Thanks,
> -mike
>
>
>
|
|
|
Powered by
FUDForum. Page generated in 0.01801 seconds
] 
Search
Help
Register
Login
Home
