| 3.3M6 - Equinox HTTP service [message #85049] |
Mon, 26 March 2007 04:23 |
 Simon Kaegi
Messages: 381
Registered: July 2009 |
Senior Member |
|
|
Hi all,
New for 3.3 M6.
-- the Jetty-based implementation of the OSGi HTTP service has been added to
the Platform SDK along with the bundles that provide JSP and extension
registry support. "Help" is now using this service (instead of Apache
Tomcat).--
The following bundles have been added to the platform SDK:
org.eclipse.equinox.http.jetty
org.eclipse.equinox.http.registry
org.eclipse.equinox.http.servlet
org.eclipse.equinox.jsp.jasper
org.eclipse.equinox.jsp.jasper.registry
As well as 3rd party dependency bundles from Orbit:
javax.servlet
javax.servlet.jsp
org.apache.commons.el
org.apache.commons.logging
org.apache.jasper
org.mortbay.jetty
--
One of the nice things about this change is that development of OSGi based
web applications just got a whole lot simpler as you no longer have to fetch
all these bundles yourself and if you're using the Jetty based you can just
start developing immediately. If developing with the servletbridge, you will
still have to fetch two projects from Equinox:
org.eclipse.equinox.servletbridge
org.eclipse.equinox.http.servletbridge
--
NOTE:
Changes in org.eclipse.equinox.http.registry:
-----------------------------------------------------------
As part of the API review leading up to M6 the approach for binding an
httpcontext extension to a servlet or resource extension underwent a few
changes. The schema have changed.
Previously "name" had been used in the httpcontext and "httpcontext-name" in
servlet and resource. This has been shifted to use "id" and "httpcontextId"
consistent with id usage elsewhere in the platform. The schema for the
extensions have been altered accordingly however there is some degree of
run-time backwards compatability built in (although at dev time your
extensions will need to be updated). If an "id" attribute is not present
"name" will be used instead. Likewise, if "httpcontextId" is not present the
value of "httpcontext-name" will be used instead.
The semantics of "id" are different from a simple "name" and one implication
is that references to an httpcontext extension from another bundle/namespace
must use a fully qualified "httpcontextId". Simple use where the httpcontext
and resource/servlet coexist in the same bundle/namespace can use the short
"id" to refer to an "httpContextId". (Likewise name/httpcontext-name pairs
declared in the same bundle will still work... at runtime. Again at dev time
you will need to correct errors in your extension definition)
Another behavioural change is that before it had been possible to declare
several httpcontext with the same "name" and get a built in aggregation
effect. An httpcontext identified with an "id" is unique and so no built in
aggregation support is being offered as API, although a custom HttpContext
that supports aggregation could still be used if desired.
Finally, the timing of "id" based httpcontext resolution has stronger
guarantees now. A resource / servlet that binds declares use of an
httpContextId will not be registered until the referenced httpcontext
extension is resolved and ready. Likewise if the httpcontext extension
becomes unresolved all associated servlets and resources will be
unregistered.
--
That said, for the majority of use I've seen, to update your plugin.xml...
change "name" --> "id" on your httpcontext extensions
change "httpcontext-name" --> "httpcontextId" on your resource and servlet
extensions.
-Simon
|
|
|
Powered by
FUDForum. Page generated in 0.02770 seconds
] 
Search
Help
Register
Login
Home
