Actually, on second thought:
- since this isn't the final solution anyway
- and it's much easier to just bundle this method in the BasePortlet
class (and have all portlets extend from that class) :-)
..... I'll just go ahead and include it in the BasePortlet class
(unless you've changed your mind that is).
Joe Bohn wrote:
Yes, I wasn't crazy about the implementation that I saw there either.
I think we need a more dynamic mechanism to to include the correct
elements for a particular configuration (be they UI components or other
internal elements). I also think that this is needed beyond just the
Jetty/Tomcat choice to things like DB selections, MQ implementations,
user repositories, authentication engines, etc... basically anything
that is configurable and which items like the UI may need to provide
custom logic or views.
However, in the interest of not making radical changes and getting the
UI working for tomcat I think this is the best short term approach.
However, wouldn't a utility class be a more general solution? If we
continue to include this in the Portlet classes it is very limited in
scope and can't even be used by other utility classes that are invoked
from within the portlet. We already have a situation with the logging
portlet where the knowledge of Jetty vs. Tomcat is currently necessary
in a utility class rather than the portlet (however for that particular
case it may make more sense to push the check "up" to the portlet).
Do you believe that this check will always only be needed in the
portlet code itself?
Aaron Mulder wrote:
I'm not terribly happy with the way the Tomcat/Jetty check was
done (looking for "Tomcat" or "Jetty" in the names of any interfaces the
thing implements, IIRC), so I'm a little hesitant to spread the use, but I
guess better that we do it in one place rather than have separate versions
of that check in separate modules.
You can just promote the check from BaseWebPortlet to BasePortlet,
I'd say, and make sure the method name indicates that it's for web usage
(not just "getComponentType" or something -- I don't have the code in
front of me at the moment).
Aaron
On Wed, 31 Aug 2005, Joe Bohn wrote:
There was recently some code specifically implemented under the
webmanager to determine the server on which a portlet is running (jetty
or tomcat). This was accomplished by extending the BasePortlet to
create a BaseWebPortlet and then having all of the other "web" portlets
extend from this class. The class only contains a common method (and
some constants) to determine the server type when passed the container
class.
I need this capability in other console modules (and it may be necessary
elsewhere). What are the thoughts if I remove the BaseWebPortlet class
and instead create a utility class under the console for this
function? If this is useful beyond just the console we could move it
to a more general place. Thoughts?
--
Joe Bohn
[EMAIL PROTECTED]
"He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
--
Joe Bohn
[EMAIL PROTECTED]
"He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
--
Joe Bohn
[EMAIL PROTECTED]
"He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
|
