[j-t-c] ajp and headaches

[Kevin Seguin <se...@motive.com>]

after many months of being away, i've recently gotten back into the fray of
jakarta-tomcat-connectors.  my goal is as it was many months ago - an ajp
(v1.3) connector for tomcat 4.  

after discovering that things are not working entirely correctly on the HEAD
of cvs, i started digging into the code in both places.  

maybe it's just me, but i found trying to follow the java code particularly
painful.  i realize there is some development and refactoring going on with
ajp14 and all, but man!, it ain't pretty in there :)

so, partly out of sheer necessity, and partly because i think it would be
useful, i'm considering doing a major rewrite - no, let's call it
refactoring :) - of the java code in j-t-c/jk.  the goal would be
correctness, clean up and simplification.  i would start with ajp13, but
keep in mind there is ajp14, ajp15, etc., to come.  i think i would do this
on a branch, too, call it ajp_refactoring, or something like that.

what are the thoughts on this?

thanks,
-kevin.

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [j-t-c] ajp and headaches

[Bill Barker <wb...@wilshire.com>]

----- Original Message -----
From: <co...@covalent.net>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Sunday, December 09, 2001 9:56 PM
Subject: Re: [j-t-c] ajp and headaches


> The tomcat4.0 adapter - yes. The connector code ( low level Request, etc )
> are based on MessageBytes, etc. It needs some tunning, but I
> wouldn't change it without some good reasons.
>
> I'm more interested in the low level stuff, and if possible I would like
> to keep a similar object model on both sides ( it'll help on JNI and in
> general ).
>
> The higher level needs some work...
>
> Kevin - if you have time, extracting the mapping out of tomcat4 would help
> a lot ! Also, for passing the 'route' to the session manager we need a bit

The extracting mapping logic is working fine in o.a.a.tomcat4.config.  You
can look there for a start.  What still needs work there is generating the
Alias directives (thanks Remy).  Of course, this method will be a big
improvement on the Listeners once it is in place.

> of code - we need to first "find" the session manager, then a small piece
> of code to set the jvmRoute on the request. I know this is not
> 'refactoring', but problems we need to solve asap.
>
> Costin
>
>
>
>
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [j-t-c] ajp and headaches

[co...@covalent.net]

On Sun, 9 Dec 2001, Remy Maucherat wrote:

> > maybe it's just me, but i found trying to follow the java code
> particularly
> > painful.  i realize there is some development and refactoring going on
> with
> > ajp14 and all, but man!, it ain't pretty in there :)
>
> As far as the Java portion of the connector is concerned, the code is based
> on the current HTTP connector, which I don't think is very good (obviously,
> I don't like it at all, I wouldn't be experimenting with rewriting it
> otherwise).

The tomcat4.0 adapter - yes. The connector code ( low level Request, etc )
are based on MessageBytes, etc. It needs some tunning, but I
wouldn't change it without some good reasons.

I'm more interested in the low level stuff, and if possible I would like
to keep a similar object model on both sides ( it'll help on JNI and in
general ).

The higher level needs some work...

Kevin - if you have time, extracting the mapping out of tomcat4 would help
a lot ! Also, for passing the 'route' to the session manager we need a bit
of code - we need to first "find" the session manager, then a small piece
of code to set the jvmRoute on the request. I know this is not
'refactoring', but problems we need to solve asap.

Costin







--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [j-t-c] ajp and headaches

[Remy Maucherat <re...@apache.org>]

----- Original Message -----
From: "Kevin Seguin" <se...@motive.com>
To: "Tomcat-Dev (E-mail)" <to...@jakarta.apache.org>
Sent: Sunday, December 09, 2001 12:07 PM
Subject: [j-t-c] ajp and headaches


> after many months of being away, i've recently gotten back into the fray
of
> jakarta-tomcat-connectors.  my goal is as it was many months ago - an ajp
> (v1.3) connector for tomcat 4.
>
> after discovering that things are not working entirely correctly on the
HEAD
> of cvs, i started digging into the code in both places.
>
> maybe it's just me, but i found trying to follow the java code
particularly
> painful.  i realize there is some development and refactoring going on
with
> ajp14 and all, but man!, it ain't pretty in there :)

As far as the Java portion of the connector is concerned, the code is based
on the current HTTP connector, which I don't think is very good (obviously,
I don't like it at all, I wouldn't be experimenting with rewriting it
otherwise).

> so, partly out of sheer necessity, and partly because i think it would be
> useful, i'm considering doing a major rewrite - no, let's call it
> refactoring :) - of the java code in j-t-c/jk.  the goal would be
> correctness, clean up and simplification.  i would start with ajp13, but
> keep in mind there is ajp14, ajp15, etc., to come.  i think i would do
this
> on a branch, too, call it ajp_refactoring, or something like that.
>
> what are the thoughts on this?

I also think a refctoring is needed.

Remy


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [j-t-c] ajp and headaches

[co...@covalent.net]

On Sun, 9 Dec 2001, Kevin Seguin wrote:

> after discovering that things are not working entirely correctly on the HEAD
> of cvs, i started digging into the code in both places.
>
> maybe it's just me, but i found trying to follow the java code particularly
> painful.  i realize there is some development and refactoring going on with
> ajp14 and all, but man!, it ain't pretty in there :)

I think we agreed ( Henri had some doubts ) that ajp14 will consist only
on additional messages, but all the low-level messaging stuff will be
ajp13.

For that we only need a mechanism to register new message handlers, and to
have a dispatcher that calls the right handler when a packet is received.


> so, partly out of sheer necessity, and partly because i think it would be
> useful, i'm considering doing a major rewrite - no, let's call it
> refactoring :) - of the java code in j-t-c/jk.  the goal would be
> correctness, clean up and simplification.  i would start with ajp13, but
> keep in mind there is ajp14, ajp15, etc., to come.  i think i would do this
> on a branch, too, call it ajp_refactoring, or something like that.
>
> what are the thoughts on this?

+1, I was thinking the same :-)

I would propose doing it in the main branch, but with a separate package
name.

I can roll back my changes in o.a.ajp - and revert it to the 'stable',
 and move to a new package ( I was thinking o.a.jk or o.a.jk2 - since
it'll not be specific to ajp, but will also have jni and maybe other).


Right now I'm trying to do some rewriting/optimizations/apr-istaion on the
C side, I hope to finish most of it next week ( or 2 ).


Costin






--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>