$pageTitle

Increasingly, developers are thinking about how they might use Eclipse's powerful component model and extension mechanisms in server-side environments. The possibility of a shared runtime that allows the re-use of components between client and server motivates some. Others see great promise in being able to safely modify the components and configuration of software running in a live server environment.

Running Eclipse on the server will take a different mindset (and a fair bit of work) as it questions some of the design and implementation assumptions made and adds a number of additional constraints on Eclipse's running environment. For example, in a server-side environment:

• You can make few assumptions on the control of global resources
• Your lifecycle is controlled externally
• You might be running for a very long time
• You're expected to integrate in a compliant fashion with other server elements

The key goal of this incubator is to bring existing work together to make exploration practical. The intent is to help foster solutions to the issues relating to integrating Eclipse with server-side technology. The initial emphasis is on J2EE implementations but more specifically the following issues are to be addressed (this list will evolve):

• Eclipse changes for server-side operation
• Container specific launchers
• Application Server Integration

Eclipse Changes for Server-side Operation

The Eclipse runtime was originally designed to run an IDE. It's a testament to the runtime's versatility that Eclipse is now used in a wide variety of RCP applications. Running on the server pushes this further and raises issues such as:

1. The OSGi URL Handlers Service requires two singleton operations be set with an OSGi aware version
   • URL.setURLStreamHandlerFactory(…)
   • URLConnection.setContentHandlerFactory(…)
2. The OSGi Conditional Permission Admin Specification requires the SecurityManager be set to an OSGi aware version
3. Equinox uses System Properties for configuration properties, and as the container for BundleContext properties.

For the first two items, a key challenge to be managed is the fact that in many cases, J2EE app servers set these singletons before Equinox starts. This makes it dangerous or impossible for Eclipse to set them. The third item prevents Equinox from being instantiated multiple times.

Tackling these issues will result in fairly large, cross-cutting changes in Equinox that are very difficult to resolve with individual patches. The goal for this area is to find a way to make these changes without compromising compatibility with existing Eclipse applications. Any changes will trace the HEAD very closely to facilitate integration. Ideally these changes would occur in the 3.2 timeframe.

Container Specific Launchers

One way to think of the Eclipse IDE and RCP applications (in general) is that they are started by the native executable launcher. For server-side environments, Eclipse must be launched in a different manner. Initially, this area of the incubator will focus on a launcher appropriate for embedding in a servlet container; however, other launchers will be added over time. After the issues for this first environment are addressed, other scenarios should be far easier to tackle.

The code, build instructions, and usage instructions for the servlet launcher will be part of the initial contribution for the incubator.

Application Server Integration

Resources

Please direct comments or questions to equinox-dev@eclipse.org.