Eclipse Community Forums: Equinox » Http services and contexts

Help

Home

Home » Eclipse Projects » Equinox » Http services and contexts

Show: Today's Messages :: Show Polls :: Message Navigator

Http services and contexts [message #90871]

Wed, 20 June 2007 08:34

Markus Barchfeld

Messages: 27
Registered: July 2009

Junior Member

Hi all!

I would like to run a web application inside of Eclipse (i.e. on top of
the platform). In the past this could be achieved using the internal
tomcat (although non-API). With the Tomcat it was possible to share one
instance of tomcat with the Help application. Several web application
could be started in the same Tomcat by choosing unique context names.
Of course running in the same instance also means to share the HTTP
port, but that is OK with me since (per default) a random free port was
chosen anyway.

Now I try to migrate to the OSGI HTTP service.
1) Is it possible to share one instance of an HTTP service with the Help
application (actually, I don't know how much space that saves and if it
would be really worth any effort)?
2) If I start a new HTTP service using the JettyConfiguration there are
conflicts with the help application. Although the help application uses
a context and I registered my servlets and jsps with another context the
definitions from the help application leak into my context. Which is
fatal because the help application registers a JSPFactory for /*.jsp
which makes it impossible for me to register my own JSPs.
I think that filters should be used to bind to a particular context
only, but unfortunately the help app does not define a filter.

Here is the code which starts the server (copied from
org.eclipse.help.webapp) and the HTTP registry:

d.put( "context.path", "/myapp");
d.put( "http.enabled", Boolean.TRUE);
d.put( "http.port", new Integer(8765));
d.put( "http.host", "localhost") ;
JettyConfigurator.startServer( "myapp", d) ;
Bundle bundle = Platform.getBundle("org.eclipse.equinox.http.registry");
if (bundle != null) {
if (bundle.getState() == Bundle.RESOLVED) {
bundle.start(Bundle.START_TRANSIENT);
}
}

After the server and registry have been started the URL
http://localhost:8765/myapp/index.jsp starts up Eclipse help.

One way to overrule the extension based registration (for *.jsp) would
be to register every JSP file with its specific path. But then the
servlets of the help application would still be available in my context.

I guess another way to prevent this is to register servlets and JSPs in
code and not to use the extension points. But if I want to generate the
declarations it would be easier to generate XML for the extension points
than to generate Java code.

Is there a way to use the extension point mechanism and prevent the help
definitions from mixing in?

Thanks
Markus

Report message to a moderator

Re: Http services and contexts [message #90887 is a reply to message #90871]

Wed, 20 June 2007 12:38

Simon Kaegi

Messages: 381
Registered: July 2009

Senior Member

Hi Markus,

> Is there a way to use the extension point mechanism and prevent the help
> definitions from mixing in?

Definitely. The servlets and resources extension have a "serviceSelector"
element that is for exactly this purpose.
I'll log a bug against help as we certainly don't want them to leak their
web resources into other instances of the http service.
It's a little late for 3.3 however I think this seems reasonable for 3.3.1 -
we'll see.

-Simon

Report message to a moderator

Re: Http services and contexts [message #91142 is a reply to message #90887]

Fri, 22 June 2007 19:37

Markus Barchfeld

Messages: 27
Registered: July 2009

Junior Member

>> Is there a way to use the extension point mechanism and prevent the
help definitions from mixing in?
>
> Definitely. The servlets and resources extension have a
"serviceSelector" element that is for exactly this purpose.
> I'll log a bug against help as we certainly don't want them to leak
their web resources into other instances of the http service.
> It's a little late for 3.3 however I think this seems reasonable for
3.3.1 - we'll see.

Thanks Simon, just if anybody wants to track it, the BUG id is 193530.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=193530.

For 3.3. there will be no serviceSelector before the first maintenance
release. So, what does it mean if I want to start an OSGi HTTP service
without Eclipse Help participating (and blocking JSPs entirely)?

AFAIU I can *not* use the o.e.equinox.http.registry, i.e. extension
points, to register resources and servlets (including and the Jasper
servlet for JSPs). Instead I have to switch Code base registration,
which means to create a service tracker and register resources.

Below you find some example code how this could be done. I just would be
glad to know if I am heading in the right direction.

Thanks
Markus

void registerUsingServiceTracker(final BundleContext bundleContext) {
ServiceTracker serviceTracker = new ServiceTracker(
bundleContext,
HttpService.class.getName(),
new ServiceTrackerCustomizerImplementation(bundleContext))
serviceTracker.open();
}

class ServiceTrackerCustomizerImplementation implements
ServiceTrackerCustomizer {
private final BundleContext bundleContext;

private ServiceTrackerCustomizerImplementation(
BundleContext bundleContext) {
this.bundleContext = bundleContext;
}
....
public Object addingService(ServiceReference reference) {
registerResourcesAndServlets(reference);
return null;
}

private void registerResourcesAndServlets(ServiceReference reference) {
HttpContext context = httpService.createDefaultHttpContext() ;
HttpService httpService = (HttpService)
bundleContext.getService(reference) ;
try {
httpService.registerResources("/resource", "/WebContent", context);
httpService.registerServlet(
"/servlet",
new MyServlet(),
new Hashtable(),
context) ;
} catch (Exception e) {
}
}
}

Report message to a moderator

Previous Topic:	Classloader Questions
Next Topic:	OSGi bootstrap class path with Eclipse 3.2.2

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Thu Sep 19 11:00:23 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter