Home » Eclipse Projects » Equinox » http service questions
| http service questions [message #68795] |
Fri, 23 June 2006 22:09  |
 Curtis d'Entremont
Messages: 42
Registered: July 2009 |
Member |
|
|
Hi,
For the past few days I've been prototyping the eclipse help system
running on the equinox jetty-based http service. I'm happy to say that I
was able to get everything running, both servlets and precompiled jsps.
However there were some questions along the way...
1. Where should I report problems for the code that is not yet in CVS
(still in bugzilla attachments), like the Jetty code? For example, it
prints to stdout on startup which is something we'd want to suppress.
2. I was hoping I would be able to do this using only the standard
interfaces defined by the http service (with the exception of jsps since
it's non-standard), but it seems one of the most basic operations,
starting the service, requires poking around in the internal
implementation to start specific bundles. Is this true or am I missing
something? What is the recommended way to start the service?
3. The service seems to require the use of a service tracker in order to
be located. I couldn't use the regular service lookup mechanism because
the service only starts once the first http request comes into the
ProxyServlet. So, for example, I can't request that the service come up,
register all my servlets and jsps, and listen for requests; I can only
register my stuff after the first http request has come in. Is this the
way it was intended to work or should the service start immediately once
jetty starts?
4. What is the timeline for graduating this from incubator and making it
real? (assuming all the legal work goes through)
Thanks,
Curt
|
|
|
| Re: http service questions [message #68860 is a reply to message #68795] |
Mon, 26 June 2006 18:26  |
Eclipse User |
|
|
|
Originally posted by: simon.kaegi.cognos.com
Hi Curt,
(Comments in-lined.)
> For the past few days I've been prototyping the eclipse help system
> running on the equinox jetty-based http service. I'm happy to say that I
> was able to get everything running, both servlets and precompiled jsps.
Great.
> However there were some questions along the way...
> 1. Where should I report problems for the code that is not yet in CVS
> (still in bugzilla attachments), like the Jetty code? For example, it
> prints to stdout on startup which is something we'd want to suppress.
I think using Bugzilla is still the best way; log against the "incubator"
with [server] at the front of the bug description.
The printing to stdout is caused by the logging which is configurable. Once
in CVS we can look to tie it in with the rest of Eclipse logging.
> 2. I was hoping I would be able to do this using only the standard
> interfaces defined by the http service (with the exception of jsps since
> it's non-standard), but it seems one of the most basic operations,
> starting the service, requires poking around in the internal
> implementation to start specific bundles. Is this true or am I missing
> something? What is the recommended way to start the service?
Right now it's targetting a basic OSGi environment so you're right, set-up
requires you to "start" the various Bundles.
There's nothing non-standard about this and it should be fairly simple to
integrate a launcher that activates the components on demand.
If "Help" needs to customize a launcher you might use the jetty.http
Activator as a starting point. It might also make sense to add Lazy-Start to
servlet.bridge.http. If you can describe what you're looking for I'd be
happy to help.
> 3. The service seems to require the use of a service tracker in order to
> be located. I couldn't use the regular service lookup mechanism because
> the service only starts once the first http request comes into the
> ProxyServlet. So, for example, I can't request that the service come up,
> register all my servlets and jsps, and listen for requests; I can only
> register my stuff after the first http request has come in. Is this the
> way it was intended to work or should the service start immediately once
> jetty starts?
Currently it's lazy. It probably makes sense for the service to come up when
activated. I'll re-post jetty.http to start the HttpService immediately (bug
132555) . That said, using a ServiceTracker is still a good idea.
> 4. What is the timeline for graduating this from incubator and making it
> real? (assuming all the legal work goes through)
This will probably take a bit of time as the "bundles" committers would have
to agree to make this happen. For my part I can say that I'm interested in
supporting the current components around the Jetty Http Service and JSP
support.
-Simon
|
|
|
| Re: http service questions [message #68920 is a reply to message #68860] |
Mon, 26 June 2006 22:45 |
Curtis d'Entremont
Messages: 42
Registered: July 2009 |
Member |
|
|
Thanks for the info Simon. I'll wait and see how things go with the http
service and if it happens not too late in the release I'll switch to this
service over tomcat.
About this one..
> 2. I was hoping I would be able to do this using only the standard
> interfaces defined by the http service (with the exception of jsps since
> it's non-standard), but it seems one of the most basic operations,
> starting the service, requires poking around in the internal
> implementation to start specific bundles. Is this true or am I missing
> something? What is the recommended way to start the service?
Right now it's targetting a basic OSGi environment so you're right, set-up
requires you to "start" the various Bundles.
There's nothing non-standard about this and it should be fairly simple to
integrate a launcher that activates the components on demand.
If "Help" needs to customize a launcher you might use the jetty.http
Activator as a starting point. It might also make sense to add Lazy-Start
to
servlet.bridge.http. If you can describe what you're looking for I'd be
happy to help.
- By non-standard I meant there's no starting mechanism in the HTTP
service specification. It's not a problem with the implementation, it's
something that seems missing from the specification. I thought much of the
reason for having the spec is to be implementation-agnostic, but with this
one it's not possible. I know you guys didn't write the spec, was just
wondering if you had any insight into this. Having a launcher would be
nice.. it would reduce the number of details we need to know about the
implementation. The basic requirement though is API to start the server..
it could be something as simple as stating "start these bundles in the
following order", but I wouldn't recommend that since you'd be locking in
all your bundle names as API.
Thanks again for looking into this,
Curt
|
|
|
| Re: http service questions [message #69218 is a reply to message #68920] |
Thu, 29 June 2006 20:26 |
Jim Adams
Messages: 160
Registered: July 2009 |
Senior Member |
|
|
I was wondering how you solved the issue where the help plugin currently
finds an open port and uses that. As well, how would you find out what
port was used by the service? There doesn't appear to be a way to query
the service for its base address. So if I were exposing a servlet I have
to know that the implementation uses the value of
org.osgi.service.http.port or 80.
I am currently trying to write a servlet that will piggyback on top of
whatever HttpService is out there but I need to know how to either
configure it or insure that it won't run into something else running on
my system. Just like help, it has to always be available.
Jim Adams
curtispd@ca.ibm.com wrote:
> Thanks for the info Simon. I'll wait and see how things go with the http
> service and if it happens not too late in the release I'll switch to this
> service over tomcat.
>
> About this one..
>
>
>>2. I was hoping I would be able to do this using only the standard
>>interfaces defined by the http service (with the exception of jsps since
>>it's non-standard), but it seems one of the most basic operations,
>>starting the service, requires poking around in the internal
>>implementation to start specific bundles. Is this true or am I missing
>>something? What is the recommended way to start the service?
>
> Right now it's targetting a basic OSGi environment so you're right, set-up
>
> requires you to "start" the various Bundles.
> There's nothing non-standard about this and it should be fairly simple to
> integrate a launcher that activates the components on demand.
> If "Help" needs to customize a launcher you might use the jetty.http
> Activator as a starting point. It might also make sense to add Lazy-Start
> to
> servlet.bridge.http. If you can describe what you're looking for I'd be
> happy to help.
>
> - By non-standard I meant there's no starting mechanism in the HTTP
> service specification. It's not a problem with the implementation, it's
> something that seems missing from the specification. I thought much of the
> reason for having the spec is to be implementation-agnostic, but with this
> one it's not possible. I know you guys didn't write the spec, was just
> wondering if you had any insight into this. Having a launcher would be
> nice.. it would reduce the number of details we need to know about the
> implementation. The basic requirement though is API to start the server..
> it could be something as simple as stating "start these bundles in the
> following order", but I wouldn't recommend that since you'd be locking in
> all your bundle names as API.
>
> Thanks again for looking into this,
> Curt
|
|
|
| Re: http service questions [message #69238 is a reply to message #68920] |
Thu, 29 June 2006 20:30 |
Jim Adams
Messages: 160
Registered: July 2009 |
Senior Member |
|
|
I was wondering how you solved the issue where the help plugin currently
finds an open port and uses that. As well, how would you find out what
port was used by the service? There doesn't appear to be a way to query
the service for its base address. So if I were exposing a servlet I have
to know that the implementation uses the value of
org.osgi.service.http.port or 80.
I am currently trying to write a servlet that will piggyback on top of
whatever HttpService is out there but I need to know how to either
configure it or insure that it won't run into something else running on
my system. Just like help, it has to always be available.
Jim Adams
curtispd@ca.ibm.com wrote:
> Thanks for the info Simon. I'll wait and see how things go with the http
> service and if it happens not too late in the release I'll switch to this
> service over tomcat.
>
> About this one..
>
>
>>2. I was hoping I would be able to do this using only the standard
>>interfaces defined by the http service (with the exception of jsps since
>>it's non-standard), but it seems one of the most basic operations,
>>starting the service, requires poking around in the internal
>>implementation to start specific bundles. Is this true or am I missing
>>something? What is the recommended way to start the service?
>
> Right now it's targetting a basic OSGi environment so you're right, set-up
>
> requires you to "start" the various Bundles.
> There's nothing non-standard about this and it should be fairly simple to
> integrate a launcher that activates the components on demand.
> If "Help" needs to customize a launcher you might use the jetty.http
> Activator as a starting point. It might also make sense to add Lazy-Start
> to
> servlet.bridge.http. If you can describe what you're looking for I'd be
> happy to help.
>
> - By non-standard I meant there's no starting mechanism in the HTTP
> service specification. It's not a problem with the implementation, it's
> something that seems missing from the specification. I thought much of the
> reason for having the spec is to be implementation-agnostic, but with this
> one it's not possible. I know you guys didn't write the spec, was just
> wondering if you had any insight into this. Having a launcher would be
> nice.. it would reduce the number of details we need to know about the
> implementation. The basic requirement though is API to start the server..
> it could be something as simple as stating "start these bundles in the
> following order", but I wouldn't recommend that since you'd be locking in
> all your bundle names as API.
>
> Thanks again for looking into this,
> Curt
|
|
|
Goto Forum:
Current Time: Sun Jun 30 14:21:27 GMT 2024
Powered by FUDForum. Page generated in 0.04095 seconds |
] 
Search
Help
Register
Login
Home
