Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Date: Wed, 31 Aug 2005 23:24:24 -0400 (EDT)
From: Aaron Mulder <ammulder@alumni.princeton.edu>
To: dev@geronimo.apache.org
Subject: Re: Jetty/Tomcat check in the console
In-Reply-To: <43166290.9080902@earthlink.net>
Message-ID: <Pine.LNX.4.58.0508312323000.30544@saturn.opentools.org>
References: <4315E497.50905@earthlink.net>
 <Pine.LNX.4.58.0508311912570.30544@saturn.opentools.org>
 <43165AA0.50906@earthlink.net> <43166290.9080902@earthlink.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

	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
> 
>