re: extended behaviour
Take a look at org.eclipse.equinox.http.jetty and org.eclipse.equinox.http.servletbridge + dependencies [o.e.e.http.servlet does most of the work]
These two Http Service implementations support wildcard extensions like "/*.jsp" or "/*.do" etc. when registering an "alias".
(Note: the slash at the front -- also this is not a regular _expression_ only the [prefix]/*.[extension] pattern is matched)
 
Paths that match a wildcard have priority over a regular alias however the longest prefix still wins.
For example... for incoming request "/a/b/c.xyz"
1) /a/b/*.xyz has priority over /a/b
2) /a/b has priority over /*.xyz
3) /a/b/c.xyz is still a perfect match and has priority over /a/b/*.xyz
 
-Simon

 

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff McAffer
Sent: Thursday, October 19, 2006 12:25 PM
To: OSGi Developer Mail List
Subject: Re: [osgi-dev] Http Service: wildcard alias


yes, Simon has taken a similar approach in Equinox with the JSP support.
        http://eclipse.org/equinox/server
Jeff



"Niclas Hedhman" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]

10/19/2006 11:03 AM

Please respond to
OSGi Developer Mail List <osgi-dev@bundles.osgi.org>

To
"OSGi Developer Mail List" <osgi-dev@bundles.osgi.org>
cc
Subject
Re: [osgi-dev] Http Service: wildcard alias







On 10/19/06, Nikunj Mehta <[EMAIL PROTECTED]> wrote:
I am new to OSGI and I am trying to use OSGI for a web app. Is it legal
in OSGI to register a wild card alias with HttpService?


I hope you understand Peter's reply. OSGi Http Service specification is explicitly made simple, and therefor doesn't support aliases such as "*.jsp", which I assume you are fishing for.


Now that said, that is specification. Nothing stops you from introducing your own servlet handler which could extend the spec behaviour. You would then to some extent sacrifice being compatible with all other implementations.

You could either;
1. Create your own Http service, which describes this extended behavior,
2. Create a WhiteBoard pattern servlet registration mechanism.

The latter is about creating a BundleA which registers a ServletB with the standard Http Service. It also looks for Servlets being registered to the OSGi Framework as a service, and if found looks for a particular service property which contains the 'pattern'. That pattern and reference to the registered servlet is handed to the ServletB.
Now, those servlets that require the pattern-matching, does not look up the Http Service and register themselves there, but instead register the servlet in the OSGi frameworks service registry, i.e. bundleContext.registerService (). You may need to do something similar for resources.

In fact, I think that this usage pattern should be the default way of the spec and with a little nudge, perhaps we could see this coming into a future spec... <nudge> <nudge>


Cheers
Niclas
_______________________________________________
OSGi Developer Mail List
osgi-dev@bundles.osgi.org
http://bundles.osgi.org/mailman/listinfo/osgi-dev

 
     This message may contain privileged and/or confidential information.  If you have received this e-mail in error or are not the intended recipient, you may not use, copy, disseminate or distribute it; do not open any attachments, delete it immediately from your system and notify the sender promptly by e-mail that you have done so.  Thank you.
_______________________________________________
OSGi Developer Mail List
osgi-dev@bundles.osgi.org
http://bundles.osgi.org/mailman/listinfo/osgi-dev

Reply via email to