Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between pages "Web Tools Requirements 1.5" and "Adaptor Hooks"

(Difference between pages)
(→‎Release milestones and release candidates)
 
 
Line 1: Line 1:
−
=Eclipse Web Tools Project DRAFT 1.5 Plan=
+
== Overview ==
 +
Since Eclipse 3.0 the Framework Adaptor API has been available in the Equinox OSGi Framework.  A framework adaptor implementation is called upon by the Equinox OSGi Framework to perform a number of tasks.  A framework adaptor may be used to add functionality to the framework.
  
−
'''Revised draft''' January 24, 2006 (by Jochen Krause / WTP Requirements Group based on WTP Project 1.0 Plan
+
A single framework adaptor is specified when the framework is launched.  By default in Eclipse 3.0 this is set to the EclipseAdaptor.  In order to add new functionality in an adaptor in Eclipse 3.0 and 3.1 it is required that the adaptor implementation either re-implement the complete framework adaptor API or extend one of the existing framework adaptor implementations.  This makes it impossible for two parties to add new functionality to the framework in separate adaptors at the same time because the Equinox OSGi Framework can only be configured to use one adaptor.
−
and Eclipse Project DRAFT 3.2 Plan)
+
  
−
''Please send comments about this '''draft plan''' to the'' wtp-pmc@eclipse.org ''mailing list.''
+
In Eclipse 3.2 a new hookable adaptor has been included that is used by default as the framework adaptor. The framework adaptor API has remained unchanged for the most part in Eclipse 3.2.  What has changed is the actual implementation of the adaptor API.  A new implementation of the adaptor API is now included which provides hooks that others can implement to provide functionality to the adaptor implementation.
  
−
This document lays out the feature and API set for the next feature release of Eclipse Web Tools after 1.0, designated release 1.5.  
+
== Hookable Adaptor ==
−
This document is a draft and is subject to change, we welcome all feedback.  
+
The hookable adaptor is implemented in the package org.eclipse.osgi.baseadaptor.  This adaptor implementation provides all of the default behavior required of a FrameworkAdaptor to provide an OSGi R4 compliant Framework.  It also provides many hooks that allow others to insert additional functionality into the framework through what are called framework extension bundles.  See the OSGi Core Specification chapter 3.15 "Extension Bundles" for more information.
  
−
'''Web Tools 1.5 will be compatible with Eclipse 3.2 Releases.'''
+
Framework extension bundles are fragments of the system bundle (org.eclipse.osgi).  As a fragment they can provide extra classes which the framework can use.  A framework extension bundle can define a set of hook implementations that are configured with the hookable adaptor (using a hookconfigurators.properties file).
  
−
Plans do not materialize out of nowhere, nor are they entirely static. To ensure the planning process is transparent and open to the entire Eclipse community, we (the Eclipse Web Tools Requirement Group & the Web Tools PMC) post plans in an embryonic form and revise them throughout the release cycle.  
+
=== The Base Adaptor ===
 +
The class org.eclipse.osgi.baseadaptor.BaseAdaptor implements the interface org.eclipse.osgi.framework.adaptor.FrameworkAdaptor.  This class is used by default as the adaptor of the framework.  You should avoid extending this class, instead you should use hook implementations to add functionality to the BaseAdaptor.
  
−
The first part of the plan deals with the important matters of release deliverables, release milestones, target operating environments, and release-to-release compatibility. These are all things that need to be clear for any release, even if no features were to change.   
+
In some cases it may be impossible to do what you want with the current set of adaptor hooks. In this case you may be forced to extend the BaseAdaptor class to provide your own adaptor implementation.  If you find yourself in this situation then you should open a bug against Framework Equinox requesting a new hook method or interface.
  
−
The remainder of the plan consists of plan items for the two subprojects under the Eclipse Web Tools top-level project. The third subproject, JSF is not covered by this plan, as it is a technology project in the incubator state. Each plan item covers a feature or API that is to be added to Web Tools, or some aspect of Web Tools that is to be improved. Each plan item will have its own entry in the Eclipse bugzilla database, with a title and a concise summary (usually a single paragraph) that explains the work item at a suitably high enough level so that everyone can readily understand what the work item is without having to understand the nitty-gritty detail.  
+
=== The Hook Registry ===
 +
The hook registry is implemented in the class org.eclipse.osgi.baseadaptor.HookRegistry. The hook registry is used to store all the hooks configured in the framework. When the hook registry is initialized it will discover all the hook configurators installed in the framework and will call on them to add hooks to the registry.  The BaseAdaptor uses the hook registry at runtime to lookup and use the different hooks configured with the registry.
  
−
Not all plan items represent the same amount of work; some may be quite large, others, quite small. Some plan items may involve work that is localized to a single Platform component; others may involve coordinated changes to several components; other may pervade the entire Platform. Although some plan items are for work that is more pressing that others, the plan items appear in no particular order.  
+
==== Hook Configurators ====
 +
Hook configurators must implement the org.eclipse.osgi.baseadaptor.HookConfigurator interface.  Hook configurators can add one or more hook implementations to the hook registry using the various add methods on the registry.
  
−
With the previous release as the starting point, this is the plan for how we will enhance and improve it. Fixing bugs, improving test coverage, documentation, examples, performance tuning, usability, etc. are considered routine ongoing maintenance activities and are not included in this plan unless they would also involve a significant change to the API or feature set, or involve a significant amount of work. The intent of the plan is to account for all interesting feature work.  
+
==== Discovering Hook Configurators ====
 +
In order for a hook configurator to be discovered by the hook registry its implementation must be accessable by the framework's classloader.  This implies that hook configurators must be built into the framework itself (org.eclipse.osgi) or be supplied by a framework extension bundle. Again a framework extension bundle is really just a fragment to Framework (i.e org.eclipse.osgi or the System Bundle).
  
 +
A hook configurator also must be declared in one of the following ways to indicate to the hook registry which classes should be loaded as hook configurators.
  
−
The current status of each plan item is noted:  
+
===== hookconfigurators.properties files =====
 +
A hookconfigurators.properties file can be used to declare a list of hook configator classes.  The key hook.configurators is used in a hook configurators properties file to specify a comma separated list of fully qualified hook configurator classes.  For example, the Equinox Framework (org.eclipse.osgi) is shipped with a default set of hook configurators specified a hookconfigurators.properties file included in the org.eclipse.osgi.jar:
  
−
'''High Priority''' plan item - A high priority plan item is one that we have decided to address for the release (committed).  
+
<code>
 +
hook.configurators=
 +
    org.eclipse.osgi.internal.baseadaptor.BaseHookConfigurator,
 +
    org.eclipse.osgi.internal.baseadaptor.DevClassLoadingHook,
 +
    org.eclipse.core.runtime.internal.adaptor.EclipseStorageHook,
 +
    org.eclipse.core.runtime.internal.adaptor.EclipseLogHook,
 +
    org.eclipse.core.runtime.internal.adaptor.EclipseErrorHandler,
 +
    org.eclipse.core.runtime.internal.adaptor.EclipseAdaptorHook,
 +
    org.eclipse.core.runtime.internal.adaptor.EclipseClassLoadingHook,
 +
    org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter,
 +
    org.eclipse.core.runtime.internal.stats.StatsManager,
 +
    org.eclipse.osgi.internal.verifier.SignedBundleHook
 +
</code>
  
−
'''Medium Priority''' plan item - A medium priority plan item is one that we are considering addressing for the release.  
+
Quite a few hook configurators are automatically enabled by default withing the Equinox Framework. The only hook configurator required for a fully functional OSGi R4 Framework is the org.eclipse.osgi.internal.baseadaptor.BaseHookConfigurator.  All other configurators declared above add extra functionality needed by eclipse and can be disabled.
−
Although we are actively investigating it, we are not yet in a position to commit to it, or to say that we won't be able to address it.  
+
  
−
'''Low Priority''' plan item – A low priority plan item is one that we addressed for a release we will only address that item if one
+
Extension bundles may provide their own hookconfigurators.properties file to specify additional hook configurators.  The hook registry will discover all hookconfigurator.properties files on its classpath and will merge all declared configurator classes into one list.
−
component has addressed all high and medium priority items
+
  
−
'''Deferred''' plan item - A reasonable proposal that will not make it in to this release for some reason is marked as deferred with
+
===== osgi.hook.configurators property =====
−
a brief note as to why it was deferred. Deferred plan items may resurface as committed plan items at a later point.  
+
The osgi.hook.configurators configuration property is used to specify the list of hook configurators.  If this property is set then the list of configurators specified will be the only configurators used.  If this property is set then the hookconfigurators.properties files will not be processed for additional configurators.  This property can be used in a config.ini to lock down the set of configurators to a specific set.
  
 +
===== osgi.hook.configurators.include property =====
 +
The osgi.hook.configurators.include configuration property is used to add additional hook configurators.  This is helpful for configuring optional hook configurators.  Hooks that should be enabled by default should be included in a hookconfigurators.properties file.  This property is ignored if the osgi.hook.configurators is set.
  
−
==Release deliverables==
+
===== osgi.hook.configurators.exclude property =====
 +
The osgi.hook.configurators.include configuration property is used to exclude any hook configurators.  This is helpful for disabling hook configurators that are specified in hook configurator properties files.  This property is ignored if the osgi.hook.configurators is set.
  
−
The release deliverables have the same form as previous releases, namely:
+
== Hook interfaces ==
  
−
* Source code release for Eclipse WTP Project, available as versions tagged "R1_5" in the Eclipse WTP Project
+
=== Adaptor Hook ===
−
* CVS repository
+
−
* Eclipse WTP runtime binary and SDK download with all Eclipse pre-reqs (downloadable).
+
−
* Eclipse WTP runtime binary and SDK download (downloadable).
+
  
−
In addition, the Eclipse WTP runtime binary and SDK will be available as part of the "Callisto" update site.
+
=== Bundle File Factory Hook ===
  
−
==Release milestones and release candidates ==
+
=== Bundle File Wrapper Factory Hook ===
  
−
Release milestone occurring at roughly 6 week intervals in synchronisation with the Eclipse Platform milestone releases (starting
+
=== Bundle Watcher Hook ===
−
early 2006 latest) and will be compatible with Eclipse 3.2 releases. See [http://www.eclipse.org/projects/callisto.php Callisto Simultaneous Release] for the Eclipse Platform schedule.
+
  
−
The milestones and release candidates are:
+
=== Class Loading Hook ===
  
−
* M4  -    January 13, 2006
+
=== Class Loading Stats Hook ===
−
* M5  -    March 3, 2006 (planned API freeeze)
+
−
* M6/RC0  -    April 14, 2006 (This is Feature Freeze except for JSF and Dali).
+
−
                            (this 4/14 date is also called both RC0 and RC1 in Callisto plan).
+
−
* RC1 -    April 21, 2006
+
−
* RC2 -    May 5, 2006 (tiny grace period where any safe fix can be made).
+
−
* RC3 -    May 19, 2006 (component lead approval required for all fixes)
+
−
* RC4 -    May 31, 2006 (planned code freeze, PMC approval required for all fixes)
+
−
* RC5 -    June 20, 2006 (PMC approval and adopter sign-off required for all fixes)
+
−
* RC6 -    Jume 28, 2006 Golden Master
+
−
* Release - June 30, 2006 - WTP 1.5 Release (part of the "Callisto" joint release)
+
  
−
==Target Operating Environments==
+
=== Storage Hook ===
  
−
Eclipse WTP is built on the Eclipse platform itself.
+
== Bundle Files ==
  
−
Most of the Eclipse WTP is "pure" Java™ code and has no direct dependence on the underlying operating system. The chief dependence is therefore on Eclipse. The 1.5 release of the Eclipse WTP Project is written and compiled against version 1.4 of the Java 2 Platform APIs, and targeted to run on version 1.4 and 5.0 (1.5) of the Java 2 Runtime Environment, Standard Edition.
+
== Class Loaders ==
  
−
 
+
== Examples ==
−
Eclipse WTP is mainly tested and validated on Windows platforms, it should run on all platforms validated by the platform project:
+
−
 
+
−
[http://www.eclipse.org/eclipse/development/eclipse_project_plan_3_2.html#TargetOperatingEnvironments#TargetOperatingEnvironments Eclipse Target Operating Environments]
+
−
 
+
−
Servers integrated into Eclipse WTP deliverables will be tested and validated on the same platforms listed above. Tests for other platforms will be relying on the community support.
+
−
 
+
−
 
+
−
'''Internationalization'''
+
−
 
+
−
The Eclipse WTP is designed as the basis for internationalized products. The user interface elements provided by the Eclipse SDK components, including dialogs and error messages, are externalized. The English strings are provided as the default resource bundles. Other language support, if any, will rely on the community support.
+
−
 
+
−
==Compatibility with Other WTP Releases==
+
−
 
+
−
Project Compatibility:
+
−
 
+
−
* Full compatibility with 1.0 projects
+
−
* '''TBD'''
+
−
 
+
−
Eclipse WTP deliverables will be compatible with Eclipse 3.2. No special attention will give for being compatible with previous Eclipse versions.
+
−
 
+
−
 
+
−
==Eclipse WTP Subprojects==
+
−
 
+
−
The Eclipse WTP consists of 3 subprojects. Each subproject is covered in its own section:
+
−
 
+
−
[http://eclipse.org/webtools/wst/index.html Web Standard Tools (WST)]
+
−
 
+
−
[http://eclipse.org/webtools/jst/index.html J2EE Standard Tools (JST)]
+
−
 
+
−
[http://www.eclipse.org/webtools/jsf/index.html Java Server Faces Tools (JSF)]
+
−
 
+
−
For the WST and JST subprojects items are listed, JSF is not covered as it currently is a technology project
+
−
(in incubator state), the items listed reflect new features of the Web Tools Platform, or areas where existing
+
−
features will be significantly reworked. Common goals are listed in the “Common goals” area.
+
−
 
+
−
TBD (Each item indicates the components likely affected by that work item (many items involve coordinated changes to several components). Numbers in parentheses link to bugzilla problem reports for that plan item)
+
−
 
+
−
Note that JSF and EJB (currently incubating in the technology project) will be present in WTP 1.5 in "provisional" status - APIs in these areas will be provisional, and the release number for these two areas of functionality should be considered "0.5" rather than the overall WTP release numbering of "1.5.". Users should expect API and tool refinements in these areas, with a likelihood for more rapid (and extensive) revisions than in the base WTP code.
+
−
 
+
−
==Common goals==
+
−
===Adopter readiness===
+
−
* productization support [https://bugs.eclipse.org/bugs/show_bug.cgi?id=125751 [125751]]
+
−
* improve feature split [http://www.eclipse.org/webtools/development/arch_and_design/subsystems/SubsystemsAndFeatures.html Subsystem and Features document]
+
−
* improve API coverage (convert additional provisional areas to APIs)
+
−
 
+
−
==Web Standard Tools subproject==
+
−
 
+
−
===Architectural harmonization===
+
−
* Moving generic components to platform (common navigator [https://bugs.eclipse.org/bugs/show_bug.cgi?id=125744 [125744]], tabbed properties page [https://bugs.eclipse.org/bugs/show_bug.cgi?id=125745 [125745]])
+
−
* moving to the common undo stack (from the emf undo stack) [https://bugs.eclipse.org/bugs/show_bug.cgi?id=88011 [88011]]
+
−
 
+
−
===Web Services Support===
+
−
* WS Security [[deferred]
+
−
* upgrade to Axis 1.3 [[https://bugs.eclipse.org/bugs/show_bug.cgi?id=116308 116308]]
+
−
* Axis 2.0 Support [optional item, help wanted]
+
−
** SOAP 1.2 Support
+
−
 
+
−
===Validation Framework===
+
−
* Enhance validation framework [[http://www.eclipse.org/webtools/jst/components/j2ee/proposals/ValidatorFramework.html Proposal]]
+
−
 
+
−
==J2EE Standard Tools==
+
−
 
+
−
===Architectural harmonization===
+
−
* EJB3 (alignment with the DALI project - http://www.eclipse.org/dali/)
+
−
 
+
−
===J2EE 1.5 Support (technlogy preview)===
+
−
* EJB3 (by lightweight integration with the DALI project - http://www.eclipse.org/dali/)
+
−
* JSR 175 (Metadata) Support - only for new functionality: JSF, EJB3
+
−
* JSF Support (provided by the JSF subproject)
+
−
 
+
−
===Web Services Support===
+
−
* JSR 181 (Web Services) [optional item - help wanted]
+
−
 
+
−
===Server Runtime===
+
−
* JSR 88 Support, Advanced Server Support for one/multiple open source J2EE server [[deferred]
+
−
* Restructure Generic Server Support [[RestructureGenericServerSupportProposal]]
+

Revision as of 11:48, 22 April 2006

Overview

Since Eclipse 3.0 the Framework Adaptor API has been available in the Equinox OSGi Framework. A framework adaptor implementation is called upon by the Equinox OSGi Framework to perform a number of tasks. A framework adaptor may be used to add functionality to the framework.

A single framework adaptor is specified when the framework is launched. By default in Eclipse 3.0 this is set to the EclipseAdaptor. In order to add new functionality in an adaptor in Eclipse 3.0 and 3.1 it is required that the adaptor implementation either re-implement the complete framework adaptor API or extend one of the existing framework adaptor implementations. This makes it impossible for two parties to add new functionality to the framework in separate adaptors at the same time because the Equinox OSGi Framework can only be configured to use one adaptor.

In Eclipse 3.2 a new hookable adaptor has been included that is used by default as the framework adaptor. The framework adaptor API has remained unchanged for the most part in Eclipse 3.2. What has changed is the actual implementation of the adaptor API. A new implementation of the adaptor API is now included which provides hooks that others can implement to provide functionality to the adaptor implementation.

Hookable Adaptor

The hookable adaptor is implemented in the package org.eclipse.osgi.baseadaptor. This adaptor implementation provides all of the default behavior required of a FrameworkAdaptor to provide an OSGi R4 compliant Framework. It also provides many hooks that allow others to insert additional functionality into the framework through what are called framework extension bundles. See the OSGi Core Specification chapter 3.15 "Extension Bundles" for more information.

Framework extension bundles are fragments of the system bundle (org.eclipse.osgi). As a fragment they can provide extra classes which the framework can use. A framework extension bundle can define a set of hook implementations that are configured with the hookable adaptor (using a hookconfigurators.properties file).

The Base Adaptor

The class org.eclipse.osgi.baseadaptor.BaseAdaptor implements the interface org.eclipse.osgi.framework.adaptor.FrameworkAdaptor. This class is used by default as the adaptor of the framework. You should avoid extending this class, instead you should use hook implementations to add functionality to the BaseAdaptor.

In some cases it may be impossible to do what you want with the current set of adaptor hooks. In this case you may be forced to extend the BaseAdaptor class to provide your own adaptor implementation. If you find yourself in this situation then you should open a bug against Framework Equinox requesting a new hook method or interface.

The Hook Registry

The hook registry is implemented in the class org.eclipse.osgi.baseadaptor.HookRegistry. The hook registry is used to store all the hooks configured in the framework. When the hook registry is initialized it will discover all the hook configurators installed in the framework and will call on them to add hooks to the registry. The BaseAdaptor uses the hook registry at runtime to lookup and use the different hooks configured with the registry.

Hook Configurators

Hook configurators must implement the org.eclipse.osgi.baseadaptor.HookConfigurator interface. Hook configurators can add one or more hook implementations to the hook registry using the various add methods on the registry.

Discovering Hook Configurators

In order for a hook configurator to be discovered by the hook registry its implementation must be accessable by the framework's classloader. This implies that hook configurators must be built into the framework itself (org.eclipse.osgi) or be supplied by a framework extension bundle. Again a framework extension bundle is really just a fragment to Framework (i.e org.eclipse.osgi or the System Bundle).

A hook configurator also must be declared in one of the following ways to indicate to the hook registry which classes should be loaded as hook configurators.

hookconfigurators.properties files

A hookconfigurators.properties file can be used to declare a list of hook configator classes. The key hook.configurators is used in a hook configurators properties file to specify a comma separated list of fully qualified hook configurator classes. For example, the Equinox Framework (org.eclipse.osgi) is shipped with a default set of hook configurators specified a hookconfigurators.properties file included in the org.eclipse.osgi.jar: 

hook.configurators= 
   org.eclipse.osgi.internal.baseadaptor.BaseHookConfigurator,
   org.eclipse.osgi.internal.baseadaptor.DevClassLoadingHook,
   org.eclipse.core.runtime.internal.adaptor.EclipseStorageHook,
   org.eclipse.core.runtime.internal.adaptor.EclipseLogHook,
   org.eclipse.core.runtime.internal.adaptor.EclipseErrorHandler,
   org.eclipse.core.runtime.internal.adaptor.EclipseAdaptorHook,
   org.eclipse.core.runtime.internal.adaptor.EclipseClassLoadingHook,
   org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter,
   org.eclipse.core.runtime.internal.stats.StatsManager,
   org.eclipse.osgi.internal.verifier.SignedBundleHook

Quite a few hook configurators are automatically enabled by default withing the Equinox Framework. The only hook configurator required for a fully functional OSGi R4 Framework is the org.eclipse.osgi.internal.baseadaptor.BaseHookConfigurator. All other configurators declared above add extra functionality needed by eclipse and can be disabled.

Extension bundles may provide their own hookconfigurators.properties file to specify additional hook configurators. The hook registry will discover all hookconfigurator.properties files on its classpath and will merge all declared configurator classes into one list.

osgi.hook.configurators property

The osgi.hook.configurators configuration property is used to specify the list of hook configurators. If this property is set then the list of configurators specified will be the only configurators used. If this property is set then the hookconfigurators.properties files will not be processed for additional configurators. This property can be used in a config.ini to lock down the set of configurators to a specific set.

osgi.hook.configurators.include property

The osgi.hook.configurators.include configuration property is used to add additional hook configurators. This is helpful for configuring optional hook configurators. Hooks that should be enabled by default should be included in a hookconfigurators.properties file. This property is ignored if the osgi.hook.configurators is set.

osgi.hook.configurators.exclude property

The osgi.hook.configurators.include configuration property is used to exclude any hook configurators. This is helpful for disabling hook configurators that are specified in hook configurator properties files. This property is ignored if the osgi.hook.configurators is set.

Hook interfaces

Adaptor Hook

Bundle File Factory Hook

Bundle File Wrapper Factory Hook

Bundle Watcher Hook

Class Loading Hook

Class Loading Stats Hook

Storage Hook

Bundle Files

Class Loaders

Examples

Retrieved from "https://wiki.eclipse.org/index.php?title=Web_Tools_Requirements_1.5&oldid=4220"

Back to the top