Home » Eclipse Projects » Equinox » general purpose server-side OSGi
| general purpose server-side OSGi [message #60945] |
Thu, 09 February 2006 18:07  |
Eclipse User |
|
|
|
Originally posted by: jfallows.txesystems.com
Folks,
I've just started taking a look at the Equinox BridgeServlet and Servlet
extension point for OSGi - very cool and useful stuff!
Previously, we had to solve the problem of starting OSGi in a web-based
environment by factoring our code so as to rendezvous on public
interfaces that were loaded in the web-app classloader, with
implementations loaded as part of the bundle.
We are very enthusiastic to see the progress being made on this
important general-purpose solution that uses standard J2EE APIs, like
javax.servlet.Servlet to do the rendezvous instead - very clever!
Looking at the current implementation on 3.2 HEAD, we have a few questions.
Q1. HttpServletRequest.getContextPath()
If the BridgeServlet is running in the host Web Container under context
/bridge and a Servlet is registered via OSGi under context /osgi, then
the URL to access the OSGi Servlet is /bridge/osgi. Perhaps the OSGi
HttpServletRequest.getContextPath() should return "/bridge/osgi" in this
scenario?
Q2. ServletContext.getInitParameter(String paramName)
The OSGi ServletContext seems to be delegating back to the host
ServletContext for the BridgeServlet to lookup ServletContext
initialization parameters (specified as <context-param> in web.xml).
Perhaps each OSGi ServletContext should have independent context
initialization parameters? Otherwise, two OSGi servlet bundles could
not configure the same context initialization parameter differently.
Q3. Extension point syntax
How much of the standard J2EE web.xml syntax will eventually be
supported? If not 100%, which parts would be omitted and why?
Q4. Compiling JSPs on-demand
It seems as though JSPs must be pre-compiled because there is currently
no support for on-demand compilation. However, pre-compilation is tied
to a specified vendor implementation, because the translated Java code
extends a vendor-specific class. Are there any plans to leverage the
host container JSP Runtime to support on-demand JSP compilation for OSGi
bundles?
Finally, if you would like some help with designing and coding these
features, I'd be happy to help. :)
Kind Regards,
John Fallows.
--
Author: Pro JSF and Ajax: Building Rich Internet Components
http://apress.com/book/bookDisplay.html?bID=10044
|
|
|
| Re: general purpose server-side OSGi [message #61322 is a reply to message #60945] |
Fri, 10 February 2006 22:53  |
| Eclipse User |
|
|
|
Originally posted by: simon.kaegi.cognos.com
Hi John,
These are all good questions.
> Q1. HttpServletRequest.getContextPath()
> If the BridgeServlet is running in the host Web Container under
> context /bridge and a Servlet is registered via OSGi under context /osgi,
> then the URL to access the OSGi Servlet is /bridge/osgi. Perhaps the OSGi
> HttpServletRequest.getContextPath() should return "/bridge/osgi" in this
> scenario?
When you register a servlet the alias you use just becomes the servlet
path. The context path isn't affected in this case.
> Q2. ServletContext.getInitParameter(String paramName)
> The OSGi ServletContext seems to be delegating back to the host
> ServletContext for the BridgeServlet to lookup ServletContext initialization
> parameters (specified as <context-param> in web.xml). Perhaps each OSGi
> ServletContext should have independent context initialization parameters?
> Otherwise, two OSGi servlet bundles could not configure the same context
> initialization parameter differently.
The current OSGi HttpService doesn't deal with multiple ServletContexts. A
valid implementation here would be to return nothing. I left it as it is
primarily as a convenience. Depending on seeing these parameters is
definitely not portable.
> Q3. Extension point syntax
> How much of the standard J2EE web.xml syntax will eventually be supported?
> If not 100%, which parts would be omitted and why?
Eventually, I'd like to support it all, however for the time being the
syntax while similar to web.xml will only handle what's available in the
OSGi HttpService.
In terms of what "could" be added easily I think filters and listeners are
good candidates. I suspect most of the other more static declarative
elements might be very hard to add though.
> Q4. Compiling JSPs on-demand
> It seems as though JSPs must be pre-compiled because there is currently no
> support for on-demand compilation. However, pre-compilation is tied to a
> specified vendor implementation, because the translated Java code extends a
> vendor-specific class. Are there any plans to leverage the host container
> JSP Runtime to support on-demand JSP compilation for OSGi bundles?
For the reasons you mention (and more) I don't think leveraging the host
containers JSP runtime is feasible. I'd really like to see if we can't
house the runtime and compilation directly inside the OSGi framework. On
this one issue I could really use some help both for design and the actual
coding.
-Simon
|
|
|
| Re: general purpose server-side OSGi [message #61470 is a reply to message #61322] |
Tue, 14 February 2006 18:20 |
| Eclipse User |
|
|
|
Originally posted by: jfallows.txesystems.com
Hi Simon,
Thanks very much for your reply. I have some follow-up points below.
Simon Kaegi wrote:
> Hi John,
>
> These are all good questions.
>> Q1. HttpServletRequest.getContextPath()
>> If the BridgeServlet is running in the host Web Container under
>> context /bridge and a Servlet is registered via OSGi under context /osgi,
>> then the URL to access the OSGi Servlet is /bridge/osgi. Perhaps the
>> OSGi
>> HttpServletRequest.getContextPath() should return "/bridge/osgi" in this
>> scenario?
> When you register a servlet the alias you use just becomes the servlet
> path. The context path isn't affected in this case.
Okay. Suppose the BridgeServlet is deployed to the host Web container
with context-path "/host-webapp" and servlet-path "/equinox-bridge".
Now, a Servlet is registered using equinox at alias "/osgi-servlet".
What are the values for context-path and servlet-path in the context of
"/osgi-servlet"?
It seems to have the following configuration:
context-path "/host-webapp"
servlet-path "/osgi-servlet"
....which would lose information about "/equinox-bridge" in the path.
Many Web technologies construct absolute webapp URLs simply by prefixing
the context-path. That would seem to break in this scenario due to the
lost information, right?
In other words, a URL intended for
/host-webapp/equinox-bridge/osgi-servlet/...
would instead be written as
/host-webapp/osgi-servlet/...
resulting in a 404 Not Found.
>> Q2. ServletContext.getInitParameter(String paramName)
>> The OSGi ServletContext seems to be delegating back to the host
>> ServletContext for the BridgeServlet to lookup ServletContext
>> initialization parameters (specified as <context-param> in web.xml).
>> Perhaps each OSGi ServletContext should have independent context
>> initialization parameters? Otherwise, two OSGi servlet bundles could
>> not configure the same context initialization parameter differently.
> The current OSGi HttpService doesn't deal with multiple ServletContexts.
> A valid implementation here would be to return nothing. I left it as it
> is primarily as a convenience. Depending on seeing these parameters is
> definitely not portable.
I suspect that the OSGi HttpServlet should become aware of multiple
ServletContexts to properly isolate itself from the host webapp and
allow Web OSGi plugins to be introduced without the need for additional
configuration. Do you agree?
>> Q3. Extension point syntax
>> How much of the standard J2EE web.xml syntax will eventually be
>> supported? If not 100%, which parts would be omitted and why?
> Eventually, I'd like to support it all, however for the time being the
> syntax while similar to web.xml will only handle what's available in the
> OSGi HttpService.
What is the process for evolving the OSGi HttpService? I imagine the
goal is to be 100% portable with Servlet code originally written for
traditional J2EE containers. Is this correct?
> In terms of what "could" be added easily I think filters and listeners
> are good candidates. I suspect most of the other more static declarative
> elements might be very hard to add though.
Filters and listeners would definitely be useful additions to the
current extension point. However, switching to a standard web.xml
syntax would be preferable over inventing something else.
Which static declarative elements are you referring to?
>> Q4. Compiling JSPs on-demand
>> It seems as though JSPs must be pre-compiled because there is
>> currently no support for on-demand compilation. However,
>> pre-compilation is tied to a specified vendor implementation, because
>> the translated Java code extends a vendor-specific class. Are there
>> any plans to leverage the host container JSP Runtime to support
>> on-demand JSP compilation for OSGi bundles?
> For the reasons you mention (and more) I don't think leveraging the host
> containers JSP runtime is feasible. I'd really like to see if we can't
> house the runtime and compilation directly inside the OSGi framework. On
> this one issue I could really use some help both for design and the
> actual coding.
Hmmm, interesting. If we house the JSP runtime inside the OSGi
framework, and then deploy the whole thing as a traditional J2EE Web
application, would we have two Web containers running one inside the other?
If we try to let the host JSP Runtime take control of compilation, does
that introduce ClassLoader issues due to a lack of visibility from the
host Web application into the relevant OSGi Web plugin?
Kind Regards,
John Fallows.
--
Author: Pro JSF and Ajax: Building Rich Internet Components
http://apress.com/book/bookDisplay.html?bID=10044
|
|
|
| Re: general purpose server-side OSGi [message #61592 is a reply to message #61470] |
Wed, 15 February 2006 14:25 |
| Eclipse User |
|
|
|
Originally posted by: skaegi.sympatico.ca
> >> Q1. HttpServletRequest.getContextPath()
> >> If the BridgeServlet is running in the host Web Container under
> >> context /bridge and a Servlet is registered via OSGi under context
/osgi,
> >> then the URL to access the OSGi Servlet is /bridge/osgi. Perhaps the
> >> OSGi
> >> HttpServletRequest.getContextPath() should return "/bridge/osgi" in
this
> >> scenario?
> > When you register a servlet the alias you use just becomes the servlet
> > path. The context path isn't affected in this case.
>
> Okay. Suppose the BridgeServlet is deployed to the host Web container
> with context-path "/host-webapp" and servlet-path "/equinox-bridge".
> Now, a Servlet is registered using equinox at alias "/osgi-servlet".
>
> What are the values for context-path and servlet-path in the context of
> "/osgi-servlet"?
>
> It seems to have the following configuration:
>
> context-path "/host-webapp"
> servlet-path "/osgi-servlet"
>
> ...which would lose information about "/equinox-bridge" in the path.
>
> Many Web technologies construct absolute webapp URLs simply by prefixing
> the context-path. That would seem to break in this scenario due to the
> lost information, right?
>
> In other words, a URL intended for
>
> /host-webapp/equinox-bridge/osgi-servlet/...
>
> would instead be written as
>
> /host-webapp/osgi-servlet/...
>
> resulting in a 404 Not Found.
>
Ok. Yes what you desribe sounds correct. This is the behaviour that is on
the HEAD.
Originally, the servlet path was not taken into consideration.
> >> Q2. ServletContext.getInitParameter(String paramName)
> >> The OSGi ServletContext seems to be delegating back to the host
> >> ServletContext for the BridgeServlet to lookup ServletContext
> >> initialization parameters (specified as <context-param> in web.xml).
> >> Perhaps each OSGi ServletContext should have independent context
> >> initialization parameters? Otherwise, two OSGi servlet bundles could
> >> not configure the same context initialization parameter differently.
> > The current OSGi HttpService doesn't deal with multiple ServletContexts.
> > A valid implementation here would be to return nothing. I left it as it
> > is primarily as a convenience. Depending on seeing these parameters is
> > definitely not portable.
>
> I suspect that the OSGi HttpServlet should become aware of multiple
> ServletContexts to properly isolate itself from the host webapp and
> allow Web OSGi plugins to be introduced without the need for additional
> configuration. Do you agree?
I'm not sure I understand the question.
The OSGi HttpService allows you to pass in initparams for each Servlet so
gives per bundle isolation of configuration at this level.
In addition HttpContexts provide similar scoping as individual Servlet
Contexts.
I think I agree ;)
> >> Q3. Extension point syntax
> >> How much of the standard J2EE web.xml syntax will eventually be
> >> supported? If not 100%, which parts would be omitted and why?
> > Eventually, I'd like to support it all, however for the time being the
> > syntax while similar to web.xml will only handle what's available in the
> > OSGi HttpService.
>
> What is the process for evolving the OSGi HttpService? I imagine the
> goal is to be 100% portable with Servlet code originally written for
> traditional J2EE containers. Is this correct?
I think the process for evolving the HttpService (if that's the right
approach) is to work with the OSGi. I think it's fair game to experiment in
the incubator and see if we can't provide some good ideas and use cases.
For the short term I'd like to be as closely aligned with OSGi HttpService
as possible.
In the future I'd like to move something resembling a java-binding of
web.xml for the service and similar for extensions.
> > In terms of what "could" be added easily I think filters and listeners
> > are good candidates. I suspect most of the other more static declarative
> > elements might be very hard to add though.
>
> Filters and listeners would definitely be useful additions to the
> current extension point. However, switching to a standard web.xml
> syntax would be preferable over inventing something else.
>
> Which static declarative elements are you referring to?
A short list from older analysis...
ServletContext Config
Session Config
Welcome files
Error Page
JNDI integration
JSP Config
Mimetype Mappings
Security - I'd be interested in any thoughts on making this dynamic but at
least for now I think this would be tough and container dependent.
>
> >> Q4. Compiling JSPs on-demand
> >> It seems as though JSPs must be pre-compiled because there is
> >> currently no support for on-demand compilation. However,
> >> pre-compilation is tied to a specified vendor implementation, because
> >> the translated Java code extends a vendor-specific class. Are there
> >> any plans to leverage the host container JSP Runtime to support
> >> on-demand JSP compilation for OSGi bundles?
> > For the reasons you mention (and more) I don't think leveraging the host
> > containers JSP runtime is feasible. I'd really like to see if we can't
> > house the runtime and compilation directly inside the OSGi framework. On
> > this one issue I could really use some help both for design and the
> > actual coding.
>
> Hmmm, interesting. If we house the JSP runtime inside the OSGi
> framework, and then deploy the whole thing as a traditional J2EE Web
> application, would we have two Web containers running one inside the
other?
>
I think that's the danger -- slippery slope.
As much as possible I'd like to leverage the appserver so that the servlet
bridge remains a "bridge" and not a full web container.
If we can leverge the JSP runtime of the appserver all the better however I
suspect this is difficult.
> If we try to let the host JSP Runtime take control of compilation, does
> that introduce ClassLoader issues due to a lack of visibility from the
> host Web application into the relevant OSGi Web plugin?
Exactly the problem.
>
> Kind Regards,
> John Fallows.
> --
> Author: Pro JSF and Ajax: Building Rich Internet Components
> http://apress.com/book/bookDisplay.html?bID=10044
|
|
|
| Re: general purpose server-side OSGi [message #61781 is a reply to message #61592] |
Thu, 16 February 2006 07:33 |
|
Simon Kaegi wrote:
>> Hmmm, interesting. If we house the JSP runtime inside the OSGi
>> framework, and then deploy the whole thing as a traditional J2EE
>> Web application, would we have two Web containers running one
>> inside the other?
> I think that's the danger -- slippery slope.
We solved such an issue with a solution everybody refers to as the
Tomcat Mess. It's a Tomcat running inside Tomcat/WebSphere/WebLogic.
It's ugly.
> As much as possible I'd like to leverage the appserver so that the
> servlet bridge remains a "bridge" and not a full web container. If we
> can leverge the JSP runtime of the appserver all the better however I
> suspect this is difficult.
We have OS specific fragments in Eclipse so why not having application
server specific fragments?
Cu, Gunnar
--
Gunnar Wagenknecht
gunnar@wagenknecht.org
http://wagenknecht.org/
|
|
|
| Re: general purpose server-side OSGi [message #61969 is a reply to message #61781] |
Fri, 17 February 2006 10:55 |
| Eclipse User |
|
|
|
Originally posted by: newsreader.infonoia.com
I probably would't be religous about how the JSP compiler+renderer is
implemented. Eclipse IDE has a full-blown Tomcat running in a plug-in,
to make help work, and no-one cares that it's not Jetty, Websphere, or
whatever. Let's just say we need a JSP compiler+renderer, define that as
requirement, and see what the most straightforward,
environment-independent solution is. A plus of "one" JSP
compiler-renderer bundle is that I could also use it when running
bundles in an OSGi-native container, which is the long-term vision, I
guess.
Wolfgang
Gunnar Wagenknecht wrote:
> Simon Kaegi wrote:
>>> Hmmm, interesting. If we house the JSP runtime inside the OSGi
>>> framework, and then deploy the whole thing as a traditional J2EE
>>> Web application, would we have two Web containers running one
>>> inside the other?
>
>> I think that's the danger -- slippery slope.
>
> We solved such an issue with a solution everybody refers to as the
> Tomcat Mess. It's a Tomcat running inside Tomcat/WebSphere/WebLogic.
> It's ugly.
>
>> As much as possible I'd like to leverage the appserver so that the
>> servlet bridge remains a "bridge" and not a full web container. If we
>> can leverge the JSP runtime of the appserver all the better however I
>> suspect this is difficult.
>
> We have OS specific fragments in Eclipse so why not having application
> server specific fragments?
>
> Cu, Gunnar
>
|
|
|
| Re: general purpose server-side OSGi [message #61992 is a reply to message #61969] |
Fri, 17 February 2006 12:13 |
 Richard Backhouse
Messages: 19
Registered: July 2009 |
Junior Member |
|
|
In a typical JSP Container all jsp requests (*.jsp) are mapped to a
JspServlet. This servlet is really just a mini container that handles
all JSP requests, translating them when required and then directing the
request to the generated JSPServletWrapper.
The most generic JSP Container that I am aware of is Jasper which is
used in Tomcat (and Jetty I think). It should be possible to create a
Jasper Bundle that provides a servlet extension point for mapping
(*.jsp). As the Jasper JspServlet (org.apache.jasper.servlet.JspServlet)
expects to find the jsp source files on disk it would have to be
extended or replaced with one that has access to the extension registry
and is able to pull the jsp source files out of the bundles that have
specified them. It should also be possible for this Jasper Bundle to
provide other services such as JSP precompiling and validation etc.
Another potential issue would be the actual compiling of the generated
JSP servlet class. Using the standard jdk compiler found in tools.jar
would be problematic as it expects to receive a set of absolute
classpath entries. In the OSGi world access to the classpaths provided
by the bundles classloader would be pretty hard to do. However, Jasper
does support the use of the Eclipse JDT compiler which is far less
restrictive on the classpaths it expects (In fact it uses the
WebApplications classloader to get access to dependent classes instead
of using real classpaths).
Richard
Wolfgang Gehner wrote:
> I probably would't be religous about how the JSP compiler+renderer is
> implemented. Eclipse IDE has a full-blown Tomcat running in a plug-in,
> to make help work, and no-one cares that it's not Jetty, Websphere, or
> whatever. Let's just say we need a JSP compiler+renderer, define that as
> requirement, and see what the most straightforward,
> environment-independent solution is. A plus of "one" JSP
> compiler-renderer bundle is that I could also use it when running
> bundles in an OSGi-native container, which is the long-term vision, I
> guess.
>
> Wolfgang
>
> Gunnar Wagenknecht wrote:
>
>> Simon Kaegi wrote:
>>
>>>> Hmmm, interesting. If we house the JSP runtime inside the OSGi
>>>> framework, and then deploy the whole thing as a traditional J2EE
>>>> Web application, would we have two Web containers running one
>>>> inside the other?
>>
>>
>>> I think that's the danger -- slippery slope.
>>
>>
>> We solved such an issue with a solution everybody refers to as the
>> Tomcat Mess. It's a Tomcat running inside Tomcat/WebSphere/WebLogic.
>> It's ugly.
>>
>>> As much as possible I'd like to leverage the appserver so that the
>>> servlet bridge remains a "bridge" and not a full web container. If we
>>> can leverge the JSP runtime of the appserver all the better however I
>>> suspect this is difficult.
>>
>>
>> We have OS specific fragments in Eclipse so why not having application
>> server specific fragments?
>>
>> Cu, Gunnar
>>
|
|
|
| Re: general purpose server-side OSGi [message #62016 is a reply to message #61992] |
Fri, 17 February 2006 21:54 |
| Eclipse User |
|
|
|
Originally posted by: newsreader.infonoia.com
Agree with Richard.
Afterthought on reusing the specific container: different containers
have their own taglib implementations, as for JSTL/Standard.jar so
creating JSPs that fit "all sizes" is difficult. E.g. Resin has its own,
Tomcat doesn't come with one, etc. etc. And then there are levels: 2.3,
2.4 etc.
So should a bundle be tagged 2.3, 2.4? A 2.4 Jasper bundle feels right.
W.
|
|
| |
| Re: general purpose server-side OSGi [message #62059 is a reply to message #62039] |
Sat, 18 February 2006 18:17 |
| Eclipse User |
|
|
|
Originally posted by: newsreader.infonoia.com
For my understanding, why would the container need tlds? That is if we
write a jasper bundle, in osgi, separate of the container. (like a
jasper bundle for Felix).
Wolfgang
|
|
| |
| Re: general purpose server-side OSGi [message #62198 is a reply to message #62081] |
Sun, 19 February 2006 17:49 |
| Eclipse User |
|
|
|
Originally posted by: newsreader.infonoia.com
I think I had read your post the wrong way. You are saying that "if we
use the container to compile JSPs, we are non-compliant." No dispute.
I think a jasper bundle would be a solution. This is not the container
compiling, it is an osgi bundle.
W.
Richard Backhouse wrote:
> To be able to translate a JSP the JSP Container would have to have the
> details of the available Tag Libraries that have been installed. Without
> the TLD the JSP container would not know which tag classes to generate
> code to use etc.
>
> Wolfgang Gehner wrote:
>> For my understanding, why would the container need tlds? That is if we
>> write a jasper bundle, in osgi, separate of the container. (like a
>> jasper bundle for Felix).
>> Wolfgang
|
|
| |
| Re: general purpose server-side OSGi [message #62246 is a reply to message #61322] |
Sun, 19 February 2006 21:08 |
Harald Niesche
Messages: 23
Registered: July 2009 |
Junior Member |
|
|
Simon Kaegi wrote:
>> Q4. Compiling JSPs on-demand
>> It seems as though JSPs must be pre-compiled because there is
>> currently no support for on-demand compilation. However,
>> pre-compilation is tied to a specified vendor implementation, because
>> the translated Java code extends a vendor-specific class. Are there
>> any plans to leverage the host container JSP Runtime to support
>> on-demand JSP compilation for OSGi bundles?
> For the reasons you mention (and more) I don't think leveraging the host
> containers JSP runtime is feasible. I'd really like to see if we can't
> house the runtime and compilation directly inside the OSGi framework. On
> this one issue I could really use some help both for design and the
> actual coding.
I have started some experimentation with jasper, since it now compiles
using the jdt compiler and doesn't need ant / javac. (Excellent
suggestion by Richard Backhouse, and yes, it is used by both Tomcat and
Jetty.)
The Jasper servlet accesses JSP files and tag library descriptors
through the ServletContext.getResourceAsStream method which in the OSGi
HttpService uses the HttpContext provided when the servlet got
registered. The default HttpContext uses bundle.getResource() to obtain
the resource, which in turn calls getResource() on the bundle's classloader.
If the jasper bundle simply imports everything using some variation of
the "DynamicImport-Package: *" header, the JspServlet can be used
unchanged with only minimal code in the BundleActivator. (I have a
working prototype of this).
As an alternative, a specialized HttpContext could be provided that
checks that the requested resource ends in ".jsp" (or ".jspx" or ".tld").
The special HttpContext would also remove the servlet path from the
resource name (jasper appends servletPath and pathInfo to get the
complete path of the jsp file). The bridge servlet and the native OSGi
HttpService seem to have some differences here that would make it harder
to write bundles that work with both kinds of HttpService without the
prefix adjusting.
For discovery of tag libraries and tag files (I assume, haven't really
checked the specs) it would be necessary to implement
ServiceContext.getResourcePaths() -- but that means we need support from
the bridge servlet or HttpService implementation. So I'd rather leave
that out and tolerate having to put tag library descriptors somewhere on
the classpath.
For JSP registration, it should be possible to make the HttpContext
implementation use some JSP-registration services or extension points,
but I haven't done any work on that.
Interested?
Harald
|
|
|
| Re: general purpose server-side OSGi [message #62294 is a reply to message #62246] |
Mon, 20 February 2006 16:40 |
| Eclipse User |
|
|
|
Originally posted by: simon.kaegi.cognos.com
Hi Harald,
"Harald Niesche" wrote:
> I have started some experimentation with jasper...
This sounds like you've got something started and worth building on. Great!
> If the jasper bundle simply imports everything using some variation of
> the "DynamicImport-Package: *" header, the JspServlet can be used
> unchanged with only minimal code in the BundleActivator. (I have a
> working prototype of this).
Can you share your prototype? (warts and all is just fine with me)
I think there's considerable interest in this area and something to start
concrete implementation discussion would be excellent.
> The special HttpContext would also remove the servlet path from the
> resource name (jasper appends servletPath and pathInfo to get the
> complete path of the jsp file). The bridge servlet and the native OSGi
> HttpService seem to have some differences here that would make it harder
> to write bundles that work with both kinds of HttpService without the
> prefix adjusting.
Hmm... I use both implementations with the same servlet bundles.
The equinox embedded HttpService won't have the servlet context path
portion, but the servletPath and pathInfo should be the same.
Can you elaborate a bit. If there's a bug here we should fix it.
> For discovery of tag libraries and tag files (I assume, haven't really
> checked the specs) it would be necessary to implement
> ServiceContext.getResourcePaths() -- but that means we need support from
> the bridge servlet or HttpService implementation. So I'd rather leave
> that out and tolerate having to put tag library descriptors somewhere on
> the classpath.
> For JSP registration, it should be possible to make the HttpContext
> implementation use some JSP-registration services or extension points,
> but I haven't done any work on that.
Lots of stuff still to work out. ;)
> Interested?
Definitely!
-Simon
|
|
| | | | |
| Re: general purpose server-side OSGi [message #62414 is a reply to message #62391] |
Wed, 22 February 2006 05:52 |
| Eclipse User |
|
|
|
Originally posted by: skaegi.sympatico.ca
> Here it is: http://www.osxa.org/wiki/JasperBundle
Thanks Harald. This looks good and is definitely easy enough to follow.
I'll try it out and report back.
> The bundle should work with stand-alone equinox and the bridge servlet,
> but I have tested only with equinox and the org.eclipse.equinox.http
> plugin (this made it necessary to wrap the servlet context because it
> was throwing UnsupportedOperation exceptions when the JspServlet called
> servletContext.getResourcePaths()).
*sigh* I've hit this and a few other similar problems many times.
A servlet 2.4 compliant implementation would really be nice to have.
> The problem with the URLClassloader was solved by simply putting a
> "wrapper" classloader as the current thread's context classloader when
> the servlet is registered -- the servlet seems to remember the
classloader.
Nice. Hmm... I wonder if destroy releases the context classloader.
-Simon
|
|
| | | |
Goto Forum:
Current Time: Tue Apr 30 11:12:47 GMT 2024
Powered by FUDForum. Page generated in 0.04454 seconds |
] 
Search
Help
Register
Login
Home
