geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: Deployment Dependencies
Date Mon, 27 Jun 2005 23:59:19 GMT

+1 to both ideas

I think we will eventually require servlet engine specific  
configurations but for the immediate future we can definitely get by  
with just a common configuration.  Once we get this working well, we  
can come back and add in a break through for the engine  
specifications configurations.  Hopefully, once we get the common  
stuff in it will be obvious how we add the non-common stuff.


On Jun 27, 2005, at 4:22 PM, Jeremy Boynes wrote:

> Aaron Mulder wrote:
>> On Mon, 27 Jun 2005, Jeremy Boynes wrote:
>>> Have we actually looked for differences? For example, I'm not a  
>>> Tomcat expert but I know there are applications out there that  
>>> use custom Valves which is a Tomcat specific implementation.
>>     It seems to me there are two possibilities.  One is to encourage
>> GBean-level configuration instead of deployment plan configuration  
>> for
>> uncommon features.  The other is to provide more generic expansion
>> elements in the deployment plan, so it gets a little uglier beyond  
>> the
>> standard features, but is still possible (you know, with
>> "web-container-param name=foo value=bar" or whatever).  If someone  
>> can
>> compile a list of those cases, we can think through which way to  
>> handle
>> them.  But I don't think this should hold up the Tomcat/Jetty plan
>> unification.  I'm definitely not willing to hold it up just in  
>> case Greg thinks up something incompatible in a future version of  
>> Jetty -- that's pretty silly IMHO.
> No-one is saying that. What I am saying is that there are  
> implementations out there other than the current Jetty and Tomcat  
> versions and we want those to work too. We don't need to implement  
> them, but we don't want to make it impossible to implement them.
> This is not hard to do. For example, you can define an interface  
> exposed by a built application that allows a container to invoke  
> it; we can have an implementation which unifies the current Jetty  
> and Tomcat runtime code (and hence the builder code as well).  
> Someone can also implement an enhanced Jetty, Tomcat, Jetty 6 or  
> MyMagicWebServer version that offers additional capabilities.
> So what I'm saying is, go ahead with unification but as part of  
> that define the interfaces and leave the door open.
> --
> Jeremy

View raw message