On Apr 21, 2009, at 7:08 PM, John Bollinger wrote:
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.
The cross-context invocation allows Pluto to "communicate" with the
Servlet that it injected into the Portlet war. Tomcat has a setting in
server.xml which when set allows the ServletContext.getContext()
method to successfully return the ServletContext for other Web
applications running in the same host. This is what Pluto is using to
get to the portal's context. See the really nice picture at http://portals.apache.org/pluto/v11/architecture.html
. Something of this nature is required since web applications
deployed in different wars generally can't communicate effectively
with each other. In some portals classes are added to the servlet
container. IIRC Pluto can also work that way but takes advantage of
this Tomcat feature to make installation of the portal simpler.
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.
You misunderstand the definition of "portlet application". A portlet
application is a war file that contains one or more portlets. Portlets
from different war files can appear on the same page in the portal. I
don't believe Pluto is attempting to control the logging that occurs
within the portlet. Unless I'm mistaken, they just want the servlet -
and any of the portal classes it uses - to use the same logging
mechanism that the portal itself is using.
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.
I can guarantee you that Pluto is not violating SRV 9.7.2. If you put
a servlet in your portlet war calls to getResource will behave as you
want. Portlets don't use that API. They use the Portlet API's version
of getResource. Pluto is the reference implementation for JSR 286 and
was the reference implementation for JSR 168, so it isn't like they
are creating something that the spec didn't envision. In fact, if the
concern you mentioned earlier regarding loading resources were true
then Pluto would be violating PLT 23.5. Presumably the TCK has
something that checks that.
FWIW, the portlet spec is much like the servlet spec. It defines what
must be provided to applications but doesn't actually say how the
container itself has to work. There are some things that the container
has to do in order to implement the spec properly, but you won't
necessarily see that called out in the spec. This is just one such
case of that.
The problem here, which you don't seem to recognize, is that Pluto
needs to do something it should be allowed to do because Tomcat allows
it. Your answer seems to be "No, you can't".
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
