Timothy Bennett wrote:
"Stephen McConnell" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
IMO the actual sources are not the important thing here (keep in mind that the core of all of this is around 3 source files). What is much more valuable is Timmothy's experience in bringing this work up-to-date.
Beyond that, there a lot of really things we could be doing to make an embedded web component really smart by leveraging the meta-model. This opens up a host of potential benefits.
Howard Henson prooved that Jetty/Avalon intergration was feasible. Timmothy has validated this against Merlin. Basically the current system demonstrates the setup of Jetty are related context objects so that a logger and service manager can be supplied to servlets. However, logger+serviceManager is only a subset of the component contact. What I would like to see is resolution of a complete component-level support which means some
rethinking of things in terms responsibilities between container and component.
Doing this here in Avalon is IMO much more productive. I also suspect that at the end of the day this would be a driver for resolution of kernel based extension (i.e. think about extending the container to be a web-server that happens to handle non-web components).
Timothy - what's your opinion?
Hehe. My opinion... hmmmmmm....
:-)
Dizzy... dazed... confused... overwhelmed... Between some of you dumping aLOL - nicely put.
weight of procedural and political obstacles that must be sorted through in
order to support this project, and others rolling out weightly technical
roadmaps of project should evolve into, quite frankly, I really don't know
what to think. There's certainly a time and place for procedure and plans,
but I feel like I've gotten the firehose turned on me.
A couple of things/observations - first - who is Timothy? I have a good idea of who you are because you and have exchanged a lot of messages concerning Web/Merlin/Avalon/etc. But those discussion need to move to [EMAIL PROTECTED] so that other people get to know you better. Second observation - your doing stuff that is in my opinion the initial steps we need to be taking towards what Avalon should be - namely a complete service-oriented-architecture and platform fully enabling web-services integration.
But that's ok... you won't get rid of me that easily ;)
Good.
Nothing against the sevak guys, but personally I prefer Henson's component. It's lightweight, simple to configure and use, and best of all my servlets have access to the Avalon ServiceManager. When I first looked at sevak, it was difficult for me to get my hands around and understand (and I don't believe servlets had access the ServiceManager, at least not in sevak-tomcat). Some of that difficulty could have been due to my "newbie-ness", my I'm glad I discovered Henson's component. I'm bringing this up to invoke a this vs. that conversation, but simply to say that alternatives to sevak do exist. And in this case, the alternative is a web component that is running in a Phoenix container that is handling hundreds of simultaneous secure B2B transactions in a commercial production server for a $800M company. This component is not a toy or a demo or a proof-of-principal.
Here is my take ... neither Servak nor Henson's component come close to what I see as the end-game. First off - neither solution provides the level of integration I'm interested in. Secondly, they both focus on the web-app as component whereas what I envisage is the plug to turn a container into a web server for any component exposing web-awareness. I do have problems with Servak in that I think it is attempting to formalize a component/web-app relationship that I think is way too limiting. Instead, I prefer to move forward with a single engine, and in doing so, keep things fluid and flexible as we experiment with total-integration. With that in mind I think Henson's work is a much better launch point.
Henson is going to be unable to contribute to the project for a period ofThere are a bunch of initiative happening at the moment concerning embedding. In your case (viewpoint of a web-app component) that isn't directly relevant, however, if we look at the "container-becomes-webserver" scenario, then a web-engine facility (container-side-component)will be needed asap - and the mechanisms for exposure of that facility transparently to other web-aware components will be introduced into the kernel.
time, so he suggested that maybe I should carry the torch for awhile (since
I was pestering him with ideas about some things I like to see happen). I'm
more than willing to take the lead on that, but currently I have no commit
rights anywhere. I'm not going to be doing anything interesting beyond my
own domain without any commit rights. For me, that's a first step -- a
community to help me grow this product even more, and to facilitate its
distribution to help others use it to build their solutions.
To help everyone here get an idea of what you have been doing I suggest you post a patch to avalon-sandbox. This will confirm to people that what we are talking about is really small, and, will provide an opportunity for people to play. With that in place you mentioned that you wanted to make a number of enhancements. You can do this though patches. While this is somewhat painful in terms of process - it is the "traditional mechanism" and will provide the opportunity for other avalon-dev committers to see you action.
Whether that comes from Wilkins, or here, or elsewhere -- it seems up in the air to me. I know my preference is to contribute here. I would like for the binaries to be co-hosted on mortbay.org because I like the idea of it being a billboard on the Jetty site for Avalon technology. But I agree with Steve that hosting the source at Avalon is more productive, and it's important for me to become a more productive part of this community. I'm impressed with Jetty. I'm impressed with what Greg and his crew has done. But I'm not very interested in becoming part of what Jetty evolves into and being a contributor to that product. This component has a *using* relationship with Jetty, but it has a *isOf* relationship with Avalon technology.
Exactly.
I would prefer not to go into incubation. That seems like overkill to me. But maybe I'm confused about the merits and upside of incubation. Do I need mentoring? Yes. Do I need guidance? Yes. Do I desire to work within a community? Yes. Do I need CVS space and commit rights? Yes. Does all that have to come via Incubation? In my opinion, no. But at the end of the day, I don't know much about the process and procedure around these parts, just a stranger in a strange land, new to most all this except for developing software.
My thoughts:
1. forget about incubation - its not relevant because we are not trying to establish a new project or new community - this is about contributing to Avalon
2. start firing away with patches (and patching include the possibility of a
patch to avalon-sandbox)
3. assume that what you contributions (via patches) may change radically as we
evolve the avalon-web solution (i.e. it's not a project, its just part of
development of Avalon's containment platform)
4. assume that actions (1), (2) and (3) may be dangerous to you health as you
may get sucked into something much bigger than what you had in mind
Cheers, Steve.
I was writing my own server framework one day and was looking for examples of how others had integrated MX4J, when I discovered Phoenix and Avalon. That discovery ruined me. I haven't been the same since. I felt like I stepped through a musty old Nardia-esque wardrobe into a wondrous and magical place. Ah! Now I understand why it's called Avalon... bingo... of course...
--
Stephen J. McConnell mailto:[EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
