geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <joe.b...@earthlink.net>
Subject Re: Jetty/Tomcat check in the console
Date Thu, 01 Sep 2005 02:08:16 GMT
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


Mime
View raw message