Leonardo, The problem with the code is that it only checks for the *Apache* bridge implementation (javax.faces.portlet.Bridge). WebSphere uses a different one, and conceivably, someone else could use another one entirely. And the other problem with ExternalContextUtils is that it looks for the existence of that class at a global level (static initializer) and marks "portlet environment available" as true/false globally. That's fine if you're talking about an environment where MyFaces is bundled with an application, but in other EE environments MyFaces is bundled at the server level, so you can't just globally declare that a portlet environment is available if those classes are available, because you'd be doing so for every single Faces application deployed in the appserver, not just those that are Faces apps running in a portlet environment. Do you agree with that assessment?
Paul, I do agree that you should write up that patch and add it to the ticket. Thanks, Curtiss Howard On Thu, Oct 27, 2011 at 12:26 AM, Leonardo Uribe <[email protected]> wrote: > Hi > > The problem with this is we are talking about two different things. > The code that detects a portlet environment was designed for: > > - JSR-301: Portlet 1.0 Bridge for JavaServer Faces 1.2 > - JSR-329: Portlet 2.0 Bridge for JavaServer Faces 1.2 > - Portlet 2.0 Bridge for JavaServer Faces 2.0 > > But what you need is another different thing. I suppose this is an > alternate bridge. Now the question is how to make it work with > MyFaces? Probably an SPI interface is a good idea, but I don't really > know if the (really very few) places that check for portlet bridge are > "well known" and will be necessary for websphere portlet bridge. It is > still unknow if it is necessary some additional hack. > > I think ExternalContextUtils works as expected, and it is not > necessary to change that part. To increase the chances this could be > added to myfaces, you can create a patch and attach it to myfaces > issue tracker, so one committer can check it and apply it. Other > option is create a web config param to enable portlet mode. It could > be more simple. > > regards, > > Leonardo Uribe > > 2011/10/26 Paul Nicolucci <[email protected]>: >> >> Hello Everyone, >> >> I've opened MYFACES-3375 and would like to propose a solution and receive >> some feedback. The proposed solution is as follows: >> >> 1) New Class PortletBridgeDetector >> - bridgeEnabled() - This method will use the Application Class loader >> to determine if a Portlet Bridge Class is available in the container and as >> such can be used to determine if Portlets are supported. >> >> 2) Class ExternalContextUtils.isPortlet - This MyFaces class/method should >> be updated to get an instance of the PortletBridgeDetector and then return >> the value of the PortletBridgeDetector.isEnabled(). >> >> We should be able to use the meta-inf/services discovery pattern to point >> to the implementation of the PortletBridgeDetector that the user wants to >> use ( WebSpherePortletBridgeDetector, ApachePortletBridgeDetector etc ). >> >> What does everyone think about this proposed solution? I'd like to start a >> discussion about it, once agreed upon a solution I'll work to implement and >> test. >> >> Thanks, >> >> Paul Nicolucci >> __________________ >> IBM - WEB Components >> [email protected] >> >> >
