You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Timothy Bennett <ex...@comcast.net> on 2003/10/18 20:07:25 UTC
Re: Jetty-Phoenix
"Leo Simons" <le...@apache.org> wrote in message
news:bmrbql$mln$1@sea.gmane.org...
> (moving this over to dev@, please direct all further comments there)
>
> Also, I'm wondering what Greg and other Jetty+Geronimo peeps have to say
> about it; I've heard rumours of Jetty moving to the asf (to perhaps be a
> geronimo subproject, or top-level), in that case it makes sense IMO to
> keep JettyPhoenix with Jetty.
>
Howard and I have also discussed keeping the with Jetty (or at least
co-hosted). I believe Howard offered to speak with Greg about getting me
committer rights to JettyPhoenix on the Jetty CVS server. In light of the
issues you've raised, then maybe keeping it at Jetty is the best solution.
I've got no problem going through incubation -- doing whatever is necessary
and required. I've also got no problem keeping it with Jetty. I'd just
like to see the component gain more visibility in the Avalon community, and
it have the opportunity to grow and mature. However that is accomplished is
obviously left to others to decide.
Timothy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Jetty-Phoenix
Posted by peter royal <pr...@apache.org>.
On Monday, October 20, 2003, at 07:47 AM, Ulrich Mayring wrote:
> peter royal wrote:
>> On Monday, October 20, 2003, at 05:32 AM, Ulrich Mayring wrote:
>>> The Avalon project desperately NEEDS some kind of web connectivity.
>>> Off the top of my head it is the only project at Apache that doesn't
>>> have it. IMHO this is embarrassing. Yeah, you can say "we have a
>>> different focus" or "CoP is a generic technology", but at the end of
>>> the day the users don't care about buzzwords, they want
>>> functionality.
>> It already has it: Sevak
>> http://cvs.apache.org/viewcvs.cgi/avalon-sandbox/sevak/
>
> It's alpha and its community has moved out with Phoenix. Do you see a
> future for Sevak?
In its current incarnation, no. But its concepts are being re-born as a
type-3 component that will include Avalon wrappers.
-pete
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Jetty-Phoenix
Posted by Ulrich Mayring <ul...@denic.de>.
peter royal wrote:
> On Monday, October 20, 2003, at 05:32 AM, Ulrich Mayring wrote:
>
>> The Avalon project desperately NEEDS some kind of web connectivity.
>> Off the top of my head it is the only project at Apache that doesn't
>> have it. IMHO this is embarrassing. Yeah, you can say "we have a
>> different focus" or "CoP is a generic technology", but at the end of
>> the day the users don't care about buzzwords, they want functionality.
>
>
> It already has it: Sevak
>
> http://cvs.apache.org/viewcvs.cgi/avalon-sandbox/sevak/
It's alpha and its community has moved out with Phoenix. Do you see a
future for Sevak?
Ulrich
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Jetty-Phoenix
Posted by Ulrich Mayring <ul...@denic.de>.
Leo Simons wrote:
>
> more seriously, Ulrich, this is an ASF community and it functions
> according to the policies the ASF sets for its communities. That
> sometimes includes incubation, a bit of a barrier to entry, etc etc. We
> could go into a debate about whether or not it makes sense that the
> things work they way they work, or we could see about getting some work
> done :D
Well, there are no ASF rules that prohibit adding to the codebase,
provided the licensing is ok. Any committer can do that for technical
reasons alone. No need to invoke bureaucracy :)
> I also disagree that we don't have web connectivity. Example: cocoon. It
> just works 'inside out'; but I suspect a large part of the reason no-one
> is building an avalon-based webserver is that you can build an
> avalon-based web application quite easily.
How? I can build a Cocoon application, but not a web application.
> this is not about ego. I see the smiley, but I still wonder what made
> that idea pop into your head...care to elaborate?
The most useful part of the Avalon project from a practical point of
view (Phoenix) has been moved out due to reasons that we probably should
not rehash, but "ego" was a big part of it, wouldn't you say?
Ulrich
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Jetty-Phoenix
Posted by Leo Simons <le...@apache.org>.
Ulrich Mayring wrote:
> Stephen McConnell wrote:
>
>> Doing this here in Avalon is IMO much more productive.
>
> The Avalon project desperately NEEDS some kind of web connectivity. Off
> the top of my head it is the only project at Apache that doesn't have
> it. IMHO this is embarrassing. Yeah, you can say "we have a different
> focus" or "CoP is a generic technology", but at the end of the day the
> users don't care about buzzwords, they want functionality.
thanks for volunteering! :P
more seriously, Ulrich, this is an ASF community and it functions
according to the policies the ASF sets for its communities. That
sometimes includes incubation, a bit of a barrier to entry, etc etc. We
could go into a debate about whether or not it makes sense that the
things work they way they work, or we could see about getting some work
done :D
I also disagree that we don't have web connectivity. Example: cocoon. It
just works 'inside out'; but I suspect a large part of the reason no-one
is building an avalon-based webserver is that you can build an
avalon-based web application quite easily.
> And now someone comes along to finally deliver an official Avalon web
> integration layer and he is sent through incubation. I think Avalon
> should be sent through incubation instead, maybe that would clear some
> egos :)
this is not about ego. I see the smiley, but I still wonder what made
that idea pop into your head...care to elaborate?
cheers!
- LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Jetty-Phoenix
Posted by Stephen McConnell <mc...@apache.org>.
Ulrich Mayring wrote:
> Stephen McConnell wrote:
>
>>
>> Doing this here in Avalon is IMO much more productive.
>
>
> The Avalon project desperately NEEDS some kind of web connectivity.
> Off the top of my head it is the only project at Apache that doesn't
> have it. IMHO this is embarrassing. Yeah, you can say "we have a
> different focus" or "CoP is a generic technology", but at the end of
> the day the users don't care about buzzwords, they want functionality.
ABSOLUTELY YES.
There is a whole market of web-service releated interests that really
NEED a comprehensive service management framework - and that framework
is not a bunch of J2EE implementations and its not some COP framework
API. Instead, it's a solution that brings together a pragmatic and
concrete COP/SOP aspects to a broad spectrum problem. Avalon has
changed in the last year - and it's still changing. We are moving from
a framework to a platform. A fundimental part of that platform is
web-service integration.
> And now someone comes along to finally deliver an official Avalon web
> integration layer and he is sent through incubation. I think Avalon
> should be sent through incubation instead, maybe that would clear some
> egos :)
LOL, ... in fact ROTFL!
Well, yes, but no, .. my take is that there *is* the classic question
of tradition/apache-way process to be taken into consideration, and in
some quarters - a certain hesitation to make the jump to the new Avalon,
but irrespective of that, I'm totally confident that we will clear these
obstacles ASAP!
Cheers, Steve.
>
>
> Ulrich
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Jetty-Phoenix
Posted by Alexis Agahi <al...@users.sf.net>.
On Monday 20 October 2003 11:32, Ulrich Mayring wrote:
> Stephen McConnell wrote:
> > Doing this here in Avalon is IMO much more productive.
>
> The Avalon project desperately NEEDS some kind of web connectivity. Off
> the top of my head it is the only project at Apache that doesn't have
> it. IMHO this is embarrassing. Yeah, you can say "we have a different
> focus" or "CoP is a generic technology", but at the end of the day the
> users don't care about buzzwords, they want functionality.
agree
> And now someone comes along to finally deliver an official Avalon web
> integration layer and he is sent through incubation. I think Avalon
> should be sent through incubation instead, maybe that would clear some
> egos :)
stay cool, I'm going to see what I can do (it wont be long belive me).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Jetty-Phoenix
Posted by Ulrich Mayring <ul...@denic.de>.
Stephen McConnell wrote:
>
> IMO servak is insufficient.
>
> You have to go a big step beyond the idea of a web-server component -
> and instead - think about the container as the web-server. Imagine a
> web-server that is containment platform. Imagine that the containement
> platform is extended to provide an HTTP interaction and session
> management layer.
I think I agree. When we look at Tomcat, then we find a number of
container-component notions in it. Tomcat has web applications,
deploy/undeploy, management, in short: it's a platform for hosting web
applications.
If we think of Avalon/Container as a platform for hosting server
applications then web applications are a subset and should be supported
on the same level as other server applications. Only then can web
applications benefit from all the neat features of the Avalon framework.
The way it is now, we need to host Tomcat (or Jetty or whatever) and
have it host web applications. Of course this is better than no web
connectivity at all. I'm sure if there were some kind of community
around this idea, then more advanced integration strategies would follow.
Ulrich
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Jetty-Phoenix
Posted by Stephen McConnell <mc...@apache.org>.
peter royal wrote:
> On Monday, October 20, 2003, at 05:32 AM, Ulrich Mayring wrote:
>
>> The Avalon project desperately NEEDS some kind of web connectivity.
>> Off the top of my head it is the only project at Apache that doesn't
>> have it. IMHO this is embarrassing. Yeah, you can say "we have a
>> different focus" or "CoP is a generic technology", but at the end of
>> the day the users don't care about buzzwords, they want functionality.
>
>
> It already has it: Sevak
>
> http://cvs.apache.org/viewcvs.cgi/avalon-sandbox/sevak/
IMO servak is insufficient.
You have to go a big step beyond the idea of a web-server component -
and instead - think about the container as the web-server. Imagine a
web-server that is containment platform. Imagine that the containement
platform is extended to provide an HTTP interaction and session
management layer. Then you are starting to move from wrapper to
integrated SOA/WSA. Integration of web-services with a
service-oriented-architecture is the big picture.
Wrappers solve problems - but they don't break now ground.
Stephen.
>
>
> -pete
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Jetty-Phoenix
Posted by peter royal <pr...@apache.org>.
On Monday, October 20, 2003, at 05:32 AM, Ulrich Mayring wrote:
> The Avalon project desperately NEEDS some kind of web connectivity.
> Off the top of my head it is the only project at Apache that doesn't
> have it. IMHO this is embarrassing. Yeah, you can say "we have a
> different focus" or "CoP is a generic technology", but at the end of
> the day the users don't care about buzzwords, they want functionality.
It already has it: Sevak
http://cvs.apache.org/viewcvs.cgi/avalon-sandbox/sevak/
-pete
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Jetty-Phoenix
Posted by Ulrich Mayring <ul...@denic.de>.
Stephen McConnell wrote:
>
> Doing this here in Avalon is IMO much more productive.
The Avalon project desperately NEEDS some kind of web connectivity. Off
the top of my head it is the only project at Apache that doesn't have
it. IMHO this is embarrassing. Yeah, you can say "we have a different
focus" or "CoP is a generic technology", but at the end of the day the
users don't care about buzzwords, they want functionality.
And now someone comes along to finally deliver an official Avalon web
integration layer and he is sent through incubation. I think Avalon
should be sent through incubation instead, maybe that would clear some
egos :)
Ulrich
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Jetty-Phoenix
Posted by Timothy Bennett <ex...@comcast.net>.
"Stephen McConnell" <mc...@apache.org> wrote in message
news:3F9739CE.8070700@apache.org...
>
> 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
> dev@avalon 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.
>
Obviously, I've finally subscribed to this list, so hopefully this will help
some get to know me. I split time working between the office and my home,
and I only subscribe to these lists from home. So, don't be surprised if my
posts spike at different times during the week.
>
> 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.
>
> There 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.
>
Having a web server/servlet container built into into the kernel can be a
powerful feature. But in domain that I work and operate in, the web server
is just another transport mechanism for moving data between points. In the
servers/apps that I build, the web server is but one gateway or portal by
which transactions move in and out of the application. Equally (or maybe
slightly less) important are the FTP and SMTP protocols. To me, all these
"servers" provides a doorway into the container by which the same data or
transaction enters the container and be handed off to other components for
decryption/authentication, application of business rules, and finally
generation of some acknowledgment or response.
So, while evolution of a web service component to full integration with the
container is an interesting endeavor, that represents only one piece of the
portal puzzle to me. FTP and SMTP services are also important to me.
> 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.
>
Correct, it will be somewhat painful, but if that represents a good place to
start, then we'll start there. I'll pull together the latest version of
JettyPhoenix, including the Ant build system, and post that some form of a
zip or tar.gz file. Someone else can handle putting in the sandbox. In
v1.3, I had removed the Phoenix BlockContext dependency, so I'd like to
re-name the project Avalon-Jetty, since it technically can run in either
Phoenix or Merlin. Look for this post maybe sometime over the weekend.
>
> 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
>
That is already quite obvious. ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Jetty-Phoenix
Posted by Stephen McConnell <mc...@apache.org>.
Timothy Bennett wrote:
>"Stephen McConnell" <mc...@apache.org> wrote in message
>news:3F91B755.4020404@apache.org...
>
>
>>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 a
>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.
>
LOL - nicely put.
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
dev@avalon 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 of
>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.
>
There 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.
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:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Jetty-Phoenix
Posted by Timothy Bennett <ex...@comcast.net>.
"Stephen McConnell" <mc...@apache.org> wrote in message
news:3F91B755.4020404@apache.org...
>
>
> 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 a
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. But that's ok... you
won't get rid of me that easily ;)
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.
Henson is going to be unable to contribute to the project for a period of
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. 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.
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.
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...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Jetty-Phoenix
Posted by Stephen McConnell <mc...@apache.org>.
Timothy Bennett wrote:
>"Leo Simons" <le...@apache.org> wrote in message
>news:bmrbql$mln$1@sea.gmane.org...
>
>
>>(moving this over to dev@, please direct all further comments there)
>>
>>Also, I'm wondering what Greg and other Jetty+Geronimo peeps have to say
>>about it; I've heard rumours of Jetty moving to the asf (to perhaps be a
>>geronimo subproject, or top-level), in that case it makes sense IMO to
>>keep JettyPhoenix with Jetty.
>>
>>
>>
>
>Howard and I have also discussed keeping the with Jetty (or at least
>co-hosted). I believe Howard offered to speak with Greg about getting me
>committer rights to JettyPhoenix on the Jetty CVS server. In light of the
>issues you've raised, then maybe keeping it at Jetty is the best solution.
>
>I've got no problem going through incubation -- doing whatever is necessary
>and required. I've also got no problem keeping it with Jetty. I'd just
>like to see the component gain more visibility in the Avalon community, and
>it have the opportunity to grow and mature. However that is accomplished is
>obviously left to others to decide.
>
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?
Stephen.
>
>Timothy
>
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
>For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Jetty-Phoenix
Posted by Leo Simons <le...@apache.org>.
Timothy Bennett wrote:
> Howard and I have also discussed keeping the with Jetty (or at least
> co-hosted). I believe Howard offered to speak with Greg about getting me
> committer rights to JettyPhoenix on the Jetty CVS server. In light of the
> issues you've raised, then maybe keeping it at Jetty is the best solution.
it all depends on where the community for this component is. If the
people that develop and use it are mostly avalon peeps, it probably
makes sense to have it over here. If its Jetty peeps, it probably makes
sense to keep it where it is now.
> I've got no problem going through incubation -- doing whatever is necessary
> and required. I've also got no problem keeping it with Jetty. I'd just
> like to see the component gain more visibility in the Avalon community, and
> it have the opportunity to grow and mature. However that is accomplished is
> obviously left to others to decide.
remember you're a big part of the decision; this is a meritocracy :D
anyway, first things first! Obvious ways to gain a little visibility
include:
- put it up on the website. We're generally happy to apply patches that
direct people at other stuff that's avalon-related
- talk about it on the mailing lists. The best way to get people to
notice something is to chat about it a little, see if anyone picks up on
yer lead. In general, feel free to send announcements to the dev and/or
user lists whenever cool stuff is happening
cheers!
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org