> -----Original Message----- > From: Aaron Mulder [mailto:[EMAIL PROTECTED] > Sent: Monday, July 25, 2005 6:12 PM > To: [email protected] > Subject: Re: GBeans: Saving Changes > > As far as the Tomcat/Jetty thing goes, that will be > interesting to explore as we think over how we should deal > with interfaces in "some future release". I mean, I think > our dependencies should ideally be expressed as "I require a > servlet 2.4-compatible web container" not "I require the > configuration named o/a/g/Server". Though to Jeremy's point, > I can also see that if you get everything working "just so" > with Jetty version X, you may not be all that eager to have > your production team deploy it onto Tomcat instead just > because that's a compatible interface.
We can make a compatible interface to a certain degree, but after that we have to deal with the capabilities of each one. I personally wanted to see Tomcat in Geronimo because I have a boat load of code that is Tomcat specific...i.e. Valves and Realms. I could use Jetty for this, but I would have to rework the code and get it into a Jetty equivalent of a Valve (is there such an animal?). Given that a majority of the user base (outside of Geronimo) out there uses Tomcat for a servlet container, we have to be careful to allow them the option to use their applications on Geronimo w/o the need to port. For a majority of the web applications, they should work for both Jetty and Tomcat...no changes needed...pick your poison for a container, add water, and stir. But for those who have invested time, money, and energy on a Tomcat technology, we want it to be as simple as possible to move over to G. This is especially true if we wish to make porting tools from other app servers. Both Tomcat and Jetty are awesome containers. I would like to see them both embraced and allow the user to configure them as they need based on their comfort level with the technology and any legacy code they are working with. > I guess we need to put some more thought into exactly what > use cases we're trying to support. > > Aaron > > On Mon, 25 Jul 2005, Dain Sundstrom wrote: > > > I have been thinking about this issue for months now and > haven't come > > to any good solutions. I think it would be cool to have imutable > > configuration, but just think it is practical at this point. The > > console and the tomcat/jetty selection issues really show off where > > our current design falls short. Anyway, I haven't come up with > > anything to solve the overall problem, but I think allowing > GBeans to > > be added and removed from a configuration is better then > what we have > > today, so I'm +1 for it. > > > > If someone has a better idea we can add in short term 1.x > timeframe, > > please speak up. Otherwise, I say make configuration > mutable and we > > can make them immutable in 2.x when something better comes along. > > > > -dain > > > > On Jul 25, 2005, at 4:56 PM, Aaron Mulder wrote: > > > > > For my part, I'm not convinced that it makes sense for > > > configurations to be immutable. I think the > export/import feature > > > would be nice -- "I finally got my web container configured 'just > > > right', now let me export it and load it into my cluster of 30 > > > boxes". I wouldn't even mind giving each configuration a unique > > > hash or something such that we could eventually down the > road add a > > > feature where you export two related configurations, and > one refers > > > to that specific build of the other. Or even having an immutable > > > flag on a configuration such that once you've marked one as > > > immutable it refuses to change in the future. > > > > > > But to tell me that properties of a configuration > shouldn't ever > > > be changed, or that GBeans shouldn't be added or removed > at runtime > > > and we should create new child configurations instead... > unless I'm > > > misunderstanding you, that just doesn't work for me. I can't > > > imagine someone customizing their web container and then > after a few > > > revs they try to load or unload or export it and discover > that they > > > now have configurations "Server", "Server HTTP v1..v5" > "Server HTTPS > > > v1..v3" > > > "Server AJP v1 & v2" "Server Keystore v1..v4" "Server > accept thread > > > pool v1" "Server JSP Compiler v1..v3" "Server request log > v1..v5", > > > and so on. > > > Much better IMHO to let them alter the "Server" configuration to > > > their heart's content, then let them export it or flag it > as locked > > > if they want to preserve a snapshot of that state. > > > > > > Thanks, > > > Aaron > > > > > > On Mon, 25 Jul 2005, Jeremy Boynes wrote: > > > > > >> Configuration bundles are meant to be immutable so you > shouldn't be > > >> adding things to them at runtime. Think of them as being > similar to > > >> library jars or other maven artifacts - things would get very > > >> confusing if you started adding classes into them as part of a > > >> build. This allows the configuration to be identified by > its ID in > > >> the same way the artifact id identifies a dependency to maven. > > >> > > >> Configuration bundles have attributes (currently modeled by > > >> exposing the GBeans they contain which is problematic) which > > >> pertain to the location in which they are being used. > The *default* > > >> values for those attributes are contained inside the bundle; the > > >> instance value is set by the environment. > > >> > > >> There are some implementation issues in Geronimo today > (short cuts > > >> taken for expediency) which obscure some of the > subtleties of this > > >> model. Some of these relate to classloading (the issues on the > > >> packaging thread), others relate to GBean persistence. > > >> > > >> I'll give a couple of examples which I hope highlight a > couple of > > >> the issues. > > >> > > >> The first anti-pattern is that configuration ids are not > unique - > > >> we reuse them for different configurations. For example, > although > > >> Tomcat and Jetty based servers are quite different we > use the same > > >> "unique" id > > >> (org/apache/geronimo/Server) for both. We also reuse ids across > > >> versions so it is impossible to tell if an application deployed > > >> against org/apache/geronimo/Server was built using M1, M2, M3 or > > >> HEAD. It is like only ever compiling against SNAPSHOT > dependencies. > > >> > > >> Secondly, if configurations are immutable then you should not be > > >> able to add GBeans to them at runtime (that would be mutating > > >> them). So how do you add a network connector? The > simplest model is > > >> to separate the web container from its connectors and > build them as > > >> separate bundles (one for the container, one for each of the > > >> connectors); if you want to add a new connector you add a new > > >> instance of e.g. the HTTPS bundle. > > >> > > >> Finally, there is the issue of instance properties - > things in the > > >> environment of where a configuration is being used that need to > > >> override the default properties that is has. For example, the > > >> default for the HTTP connector bundle might be to listen on port > > >> 8080 but on this server here it needs to be changed to be 8888. > > >> Right now we do this by mutating the configuration > installed in the > > >> store which is problematic. > > >> Instead > > >> it would be better to associate the state with the runtime and, > > >> after the bundle was loaded but before it was started, > inject those > > >> local values into it. > > >> > > >> There's a fine line between when you want to override > values on a > > >> per instance basis and when you want to define a new > configuration > > >> for with those values as defaults. There's no right solution to > > >> that but I think the type of installation plays into it: > > >> * for a desktop development environment or single server > installation > > >> then you are better just overriding properties as needed > > >> * for a clustered environment or large scale deployment > then you are > > >> better defining reusable bundles that can be easily > moved where/ > > >> when > > >> they are required > > >> > > >> As Geronimo starts being considered for larger > installations let's > > >> not forget what the original config system was designed to do. > > >> > > >> -- > > >> Jeremy > > >> > > > > > > > >
