| 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:
And also javax.servlet.http.Cookie:
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
Yep, +1
We also use it internal in MF
arjan tijms <arjan.tijms@xxxxxxxxx> schrieb am Di., 31. Aug. 2021, 11:44:
_______________________________________________Hi,
On Tue, Aug 31, 2021 at 10:26 AM Thomas Andraschko <tandraschko@xxxxxxxxxx> wrote:
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
_______________________________________________arjan tijms <arjan.tijms@xxxxxxxxx> schrieb am Mo., 30. Aug. 2021, 20:41:
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
_______________________________________________On Mon, Aug 30, 2021 at 6:56 PM arjan tijms <arjan.tijms@xxxxxxxxx> wrote:
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