geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <>
Subject Re: Unified Tomcat/Jetty Plans
Date Mon, 04 Jul 2005 05:34:25 GMT
	Dude, need you use the f-bomb?  Is this -- "Non-technical 
tip: think about the f***ing users" -- honestly your idea of a
professional interaction with your peers?

	By the way, I think you were exaggerating when you said "tell them
this is a *good* thing because we're going to keep changing things until
1.0 finally comes out".  Do you feel that's an accurate representation of
the other side of this conversation?

	As far as stability goes, I hate to say it, but we're not there
yet.  I'm going to have to make massive change to my book for the next
milestone.  The entire security system looks nothing like it did in M3,
web services were not present in M3, MDBs did not work in M3, CMP was
incomplete in M3, there was no Tomcat option at all in M3, and the list
goes on.  Add all that up, and removing 6 characters from a namespace is a
trivial change.  I don't think anyone *should* be contemplating Geronimo
for anything "serious".  We haven't even released a beta yet!

	And on the topic of coordination for builds, it's true we could do 
better.  But you know what?  Flaming me (or David, not sure who you were 
targeting, really) doesn't help.  If you'd like to propose a build, such 
as M4, and ask for a feature freeze while we prepare and test it, I think 
that would be a great idea.  It would have been nice to have done that 
before we announced that we pass the test, but let's go from where we are.

	As far as design work goes, we've historically not had the
position of review-then-commit.  I think we're trying to increase the
amount of discussion and planning on the list, but I'm not prepared to go
to a review-then-commit strategy.  Are you?  Short of that, yes, let's
talk on the list as we have been, but we also need to be prepared to make
adjustments to code that's committed as issues are identified.

	Which leads me back to the web plans.  Some of your comments
aren't clear to me.  For example: "How about defining a common interface
for the runtime bits that both Jetty and Tomcat runtimes can implement?"  
Jetty and Tomcat are operating off the same XMLBeans right now.  If
there's further unification that can be done -- by merging "runtime bits",
let's work on it.  But that doesn't have anything to do with the XML

	Honestly, the easiest path is going to be to just get XMLBeans to
ignore the namespace difference, since again, the XML content is the same.  
So I'll ask again, do you know of a way to do that?  Some flag we can send
it to forget the namespace and just try loading the elements that it
expects?  If so, let's make that change and move on, instead of arguing ad
naseum over whether that change should have been made in the past.


On Sun, 3 Jul 2005, Jeremy Boynes wrote:
> Aaron Mulder wrote:
> > Jeremy,
> > 	No need to exaggerate.  You can take a friendly tone and still
> > make your point.  
> Where was I exaggerating? You can also answer without being 
> condescending. Anyway, enough with the personal comments.
> > No one's saying that altering configuration formats is a
> > "good" thing, just that it will steadily get "worse" the more stable the
> > server gets.  And note that an "unstable" release is exactly that -- we
> > need a well-documented Milestone 4 release to direct new users to.  In the
> > mean time, I'm trying to set up a weekly build environment here, so
> > hopefully I'll put up a fresh "unstable" release from that tomorrow.
> > 
> There's "unstable" and there's "unstable" - hopefully common sense would 
> say that the first release after a major achievement like CTS complete 
> is likely to garner more attention than just another weekly and hence a 
> little more care would be in order.
> That your changes went in the revision after DB cut that release 
> indicates a massive lack of co-ordination in the project.
> > 	Finally, as for the extra mile, I have no idea how to get 
> > XMLBeans to accept an XML file that could contain one of two namespaces, 
> > but is otherwise identical in content (to handle old Jetty files).  Any 
> > constructive tips?
> > 
> Do some design work before committing changes? If you send ideas to the 
> list first then we can all review them beforehand rather than having to 
> deal with the aftermath. Maybe it was just me, but I did not realize 
> from your proposal that you were intending to invalidate all existing 
> plans.
> How about just leaving the existing stuff there? That way existing 
> applications will continue to work whilst the new stuff is being fleshed 
> out. That should actually give you more flexiblity in the run up to 1.0 
> to get the unified solution right without interfering with the 
> developing user base.
> How about defining a common interface for the runtime bits that both 
> Jetty and Tomcat runtimes can implement? That should simplify the 
> builder code allowing you to support the old schemas with less duplication.
> Have you looked at the schema conversion stuff DJ did for the J2CA 
> deployment descriptors (the stuff that handles the 1.0 DTD to 1.5 schema 
> conversion)?
> Non-technical tip: think about the f***ing users. That you needed to 
> modify all the TCK plans should have been a BIG HINT that this was not a 
> good idea. Think of the other impacts: you still need to update your own 
> book's website with the revisions, what about all the other authors?
> > 	I suppose for Tomcat we could implement a schema converter that
> > would turn the Tomcat-specific elements into container-config elements,
> > but this seems like a lot of work.  If we get a lot of feedbcak from 
> > confused Tomcat users I'll be happy to look into if further.
> > 
> It would be better to avoid confused Tomcat users in the first place. We 
> have what we have on the Tomcat side and I assume there is external doco 
> out there on it (as there is for Jetty). Keep that working whilst we 
> work out the final form.
> As an aside, I think the very presence of Tomcat-specific parameters 
> (e.g. TomcatRealm, FirstValve) indicates that the "one plan to rule 
> them" model has issues and that the LCD is not good enough. It would be 
> useful to continue that discussion.
> > Aaron
> > 
> > P.S. To address Dain's comment, I think he'd agree we need to call a 
> > moratorium on config changes once we reach a certain level of pre-1.0 
> > stability -- perhaps RC builds or whatever.
> > 
> With CTS complete there are a lot of users interested in the project. 
> The time for this is NOW. It is not just the technical mechanics, people 
> are watching how the project is operating; blatant disregard for 
> compatibility is a huge red flag for anyone contemplating anything serious.
> --
> Jeremy

View raw message