Ralph Goers wrote: > It is hard to classify something a "bug" when it is working "corectly". The > portlet spec requires that a portal container be a webapp and that it be able > to deploy and control portlets in the manner in which Pluto is doing it. That > could hardly be considered a bug.
Something is not working correctly, else there would be no bug report. Having now spent some quality time with the JSR-286 spec and re-read the PLUTO-553 description a couple more times, I think I can speak a little more intelligently about this. The portlet spec requires that "portlet applications" be web applications, and that portlet containers be or extend servlet containers. That is not the problem. The problem is that any object operating in a servlet environment, including a portlet environment, should be able to assume that the current context classloader is an appropriate one for the current operating context, yet apparently this is not always the case in Pluto. I assert that this presents problems for more than just JCL. PLUTO-553 makes some hay about "cross-context" invocations, but the portlet spec doesn't speak at all to any such activity, so I reject the premise that a portlet container must support such a thing to be considered to work correctly. > Think about it this way. The end user sees a page with multiple widgets on > it. The end user can interact with any of them. All pluto wants is that the > logging that occurs work the same no matter which portlet the end user > interacts with. That doesn't seem too unreasonable to me. All portlets in the same portlet application already log the same, else it is definitely a Pluto bug. You would have to do something very strange to make that not work. In any case, I don't think the issue is that all portlets should log the same. If that were the case then the solution would be to configure logging at the container level instead of inside each portlet application. That would provide the same logging for all portlet applications, even in the face of "cross-context" invocations. > What your answer basically says is, commons logging only supports the servlet > spec, not the portlet spec. I guess this falls in line with > https://issues.apache.org/jira/browse/LOGGING-124? Out of curiosity, if > commons-logging doesn't work in an OSGi container then how can any commons > components do logging there? I don't know about OSGi, but no, I'm not saying that commons-logging does not support the portlet spec. I see nothing in the portlet spec, including the few OSGi-related comments, that makes it any less compatible with commons-logging than the servlet spec (which it extends). On the contrary, it sounds like Pluto is probably failing to satisfy section SRV.9.7.2 of Servlet 2.4, concerning web application classloading, and I speculate that if it were meeting that requirement in a reasonable way then there would be no problem with JCL. John
