You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Joe Bohn <jo...@earthlink.net> on 2005/08/31 19:10:47 UTC
Jetty/Tomcat check in the console
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
joe.bohn@earthlink.net
"He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
Re: Jetty/Tomcat check in the console
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
OK, sounds good. I don't yet have a good enough feel on what the
ideal portlet architecture is, so I'm all for expedience in this case.
Aaron
On Wed, 31 Aug 2005, Joe Bohn wrote:
> 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
> >>>joe.bohn@earthlink.net
> >>>
> >>>"He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >>
> >
> >--
> >Joe Bohn
> >joe.bohn@earthlink.net
> >
> >"He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
> >
> >
>
> --
> Joe Bohn
> joe.bohn@earthlink.net
>
> "He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
>
>
Re: Jetty/Tomcat check in the console
Posted by Joe Bohn <jo...@earthlink.net>.
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
>>>joe.bohn@earthlink.net
>>>
>>>"He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>--
>Joe Bohn
>joe.bohn@earthlink.net
>
>"He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
>
>
--
Joe Bohn
joe.bohn@earthlink.net
"He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
Re: Jetty/Tomcat check in the console
Posted by Joe Bohn <jo...@earthlink.net>.
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
>>joe.bohn@earthlink.net
>>
>>"He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
>>
>>
>>
>>
>
>
>
>
--
Joe Bohn
joe.bohn@earthlink.net
"He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
Re: Jetty/Tomcat check in the console
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
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
> joe.bohn@earthlink.net
>
> "He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
>
>