Issue #1451  Access to Thread.setContextClassLoader()


Bug [271860]: org.eclipse.equinox.http.servlet: Avoid re-setting ThreadContextClassloader when not necessary


Here is a branch that reverts the patch that avoided setting the context classloader.

Issue #1503 Code loaded on separate ClassLoader fails with all kinds of AccessControlExceptions

OSGi keeps modules isolated from each-other by using a separate ClassLoader per module. They can only see the packages they explicitly import (and some other module explicitly exports).

Unfortunately, while creating these ClassLoaders works fine on GAE, code loaded from them suffers severe restrictions because the SecurityManager does not seem to support the extra ClassLoaders and shuts down many operations that are otherwise okay on GAE.

If this is not resolved, I might need to go back to R3. (Concierge?)

This of course is a major restriction. OSGi needs a bundle cache, into which bundles are installed and where a persistent bundle state is stored (so that, for example, bundles get re-started after a JVM restart). We will have to do without a bundle cache, with (at least) the following implications:

1. no persistent bundle state. After a JVM restart, everything is returned to square one. Actually, the whole idea of bundle state (persistent or in-memory) is at odds with App Engine, where the program spans multiple JVM that can be stopped and spawned at any time. For the same reason, dynamic modules or services also seem to be a mismatch here.
2. no native libraries. They would not work anyway.
3. no nested JAR files. At least not for now. They could probably be made to work.

On App Engine you cannot create new Threads. So bundle events will have to be dispatched immediately (synchronously) and bundles cannot be started in the background.

Felix likes to install its own SecurityManager to restrict what bundles can do. This is not possible on App Engine. I suppose FakeFelix will have to do without.

I have (in a very rough form) bundles working. I had to copy and adapt bigger pieces of Felix than I had intended to, and not much planning, design or even understanding went into the process:  I was just iteratively throwing in more stuff and hacking on it until it started to compile and run. As a result, the current code base is a mess. 
On the plus side, I could reuse entire packages of Felix as is, and this is a good exercise to understand the OSGi specs and the guts of Java classloading.

Unfortunately, I was not able to use Whiteboard out-of-the-box, but the only small thing that needed fixing was the use of reflection to provide compatibility with bundles that are pre-R4.1. 

So the next step must be a clean-up/refactoring phase. Also, I want to move the Equinox HttpServlet out of the web application and into a bundle (just like it is used in Equinox ServletBridge). Only the "framework" and its launcher should remain in the web application.

PAXSB-12: BundleUtils.getBundleContext throws java.security.AccessControlException (for accessDeclaredMembers) on Google AppEngine

AppEngine docs on reflection: 

An application is allowed full, unrestricted, reflective access to its own classes. It may query any private members, use java.lang.reflect.AccessibleObject.setAccessible(), and read/set private members. An application can also also reflect on JRE and API classes, such as java.lang.String and javax.servlet.http.HttpServletRequest. However, it can only access public members of these classes, not protected or private. An application cannot reflect against any other classes not belonging to itself, and it can not use the setAccessible() method to circumvent these restrictions.

I copied two classes from the Felix OSGi framework (ServiceRegistry and ServiceRegistrationImpl) and modified them slightly to use my FakeBundle class (instead of a real Felix bundle). Other classes on which these two depend can be used unmodified directly from the Felix jar file.

Wrapped into a FakeBundleContext this provides for an implementation of the OSGi service registration and lookup service, and it works: I can now call the Equinox HttpService bundle's activator and the HttpService gets registered.

Next step is to try to load a bundle from a separate jar file (so far, all code is in WEB-INF/classes and thus part of the framework). I am thinking the Pax Web Extender Whiteboard would a nice test case for the service registration process.

Issue #1297:  "java.util.Map.Entry is not supported by Google App Engine's Java runtime environment"

Or so the Eclipse plugin claims. I am sure this is not really the case, just an omission in the API whitelist. 

A slightly patched version of org.eclipse.equinox.http.servlet (see Snag 2) can be deployed on AppEngine. This is a Servlet that wraps an existing Servlet container to provide the OSGi HttpService.

I am running it on http://miniosgi.appspot.com/

Mind you that this is just the HttpService, with no OSGi around it at all (no ServiceRegistration for example). As such, the HttpService is not started as a bundle, but loaded as a regular jar file, and I am directly accessing "internal" packages. 
Being able to activate the bundle the proper OSGi way is the ultimate goal of this project.

I am "dropping" the source here (Mercurial bundle).

Bug [271860]: org.eclipse.equinox.http.servlet: Avoid re-setting ThreadContextClassloader when not necessary

You cannot set the ContextClassLoader in AppEngine. I'd like to add some defensive programming and not try to do that when unneccessary (re-setting to the same classloader).

Issue #1242: "javax.servlet.context.tempdir" should not be set

AppEngine does not provide access to local files, but the ServletContext

attribute "javax.servlet.context.tempdir" is set (at least on the

development server).

Google AppEngine offers a very restricted
version of the Java VM. Not being able
to create local files or start new Threads,
OSGi frameworks cannot run on top of it.

The idea is to create a useful subset
of OSGi framework and compendium services
that can be deployed on AppEngine
(and as a side-effect, on WebStart, too).