[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [faces-dev] Utilising HttpServletMapping in implementation and Portlets
|
Dear friends of JSF,
I am already on this list, no need to CC.
As I understand the history of things, originally it was thought
that in order to keep things flexible, that the Portlet API could
be implemented on top of something other than servlet technology.
And so in order to keep the Servlet API from creeping into the
Portlet API or the FacesBridge API, ExternalContext was developed
as an abstraction.
Having said that, the Portlet API has a dependency on the Servlet
API for javax.servlet.http.Part:
https://github.com/apache/portals-pluto/blob/master/portlet-api/src/main/java/javax/portlet/ClientDataRequest.java#L30
And also javax.servlet.http.Cookie:
https://github.com/apache/portals-pluto/blob/master/portlet-api/src/main/java/javax/portlet/PortletRequest.java#L950
While these are relatively minor aspects of the Servlet API, I
would put javax.servlet.http.HttpServletMapping in the same
category -- very minor.
So for the sake of consistency, my vote would be to add
ExternalContext.getHttpServletMapping(), returning
jakarta.servlet.http.HttpServletMapping
And the FacesBridge would be required to supply an
ExternalContext implementation that can handle the portlet
use-case.
Best regards to you all!
-- Neil
On 8/31/21 5:55 AM, Thomas Andraschko
wrote:
Yep, +1
We also use it internal in MF
Hi,
In general it would be great to
introduce it but then we have to think about what
happens with ExternalContext and Porlet Integration in
future.
Its not nice when we have a API
(ExternalContext) for Portlet and Servlet and then
directly Import servlet stuff.
I feel ExternalContext might have been an
over-abstraction. Unless I'm really missing something
here, why can't Portlet implementations provide an
HttpServletRequest implementation that behaves in
whatever way is needed for Portlets and throw
UnsupportedExceptions for any thing it really can't
support? Essentially that is what ExternalContext now
does anyway, but just using a different type. I
understand there's a potential difference regarding the
UnsupportedExceptions, but still.
It may have been a good idea at the start, but going
forward we may just be duplicating the existing API
without good reasons.
To me it feels a little like the hype in mid 90s (for
those who remember :P) where you coded your application
to be abstract of the UI toolkit that was being used.
Most of the times you ended up just duplicating any
existing UI toolkit within the app.
Maybe the solution is for Servlet and Portlet to come
up with better base-interfaces so
ExternalContext.getRequest() can return something a
little bit more meaningful than just Object.
Maybe we should ask NeilNeil Griffin
to chime in.
Not sure he is on this mailing list.
I assumed he was, but I'll cc him in.
For now, for Mojarra, I can use HttpServletMapping
internally using the utility method that we're now using
to calculate the mapping. That particular Mojarra
version would then not be Porlet compatible, but as it's
Faces 4, and there's no bridge for that, it would not be
compatible anyway for now. A later Mojarra version for
Faces 4 could then always be made compatible again.
Btw, the overal goal is to slim down the code by
better taking advantage of functionality in other APIs
without going through so many layers of abstractions.
Kind regards,
Arjan
Manfred Riem wrote on Mon 30 Aug
20:38:
> +1
-- All for simplifying any Faces API
Thanks!
So I'm thinking about starting with a
FacesContext.getHttpServletRequest(), AND/OR
ExternalContext.getHttpServletRequest().
For
the AND case, specify that FacesContext gets HttpServletRequest
from ExternalContext, so Portlet integrators
still only have to provide an ExternalContext
implementation. They do have to return an HttpServletRequest
implementation then.
Kind regards,
Arjan
Hi,
For Mojarra we have an open TODO to
utilize the HttpServletMapping from Servlet:
However, as usual Portlets prevent direct
usage.
Now we could move getHttpServletMapping()
to ExternalContext, but the type it returns
is in Servlet too. Wrapping that again in
Faces specific types is a little against
making the code simpler. Things will get
more complicated and tedious again.
Maybe it's time to move to supporting
HttpServletRequest only and ask whatever
technology that integrates with Faces to
supply an HttpServletRequest to Faces,
whether it's actually Servlet or not?
Thoughts?
Kind regards,
Arjan
_______________________________________________
faces-dev mailing list
faces-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/faces-dev
_______________________________________________
faces-dev mailing list
faces-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/faces-dev
_______________________________________________
faces-dev mailing list
faces-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/faces-dev