jk tags

[co...@covalent.net]

Hi,

Could we add a second tag - jk_14 ( assuming everyone agrees with this
numbering scheme and doesn't propose something better ) ?

I would also like to propose a different plan for jk2 - I'm still working
on the details, but I would like to split it in smaller ( and faster
) steps.

The first step would be a jk_15 release using the new, refactored java
code and the current C modules. It'll be a bit faster ( I don't have
numbers yet - but now the 4.0 connector is doing a lot more recycling and
is using the very efficient B2C converter from 3.3 ), it'll have the
webapp packaging ( like admin/, manager/ in 4.0, and modules/ in 3.3 ).
>From developer point of view it'll have a lot more flexibility and I hope
it'll be cleaner.


I would also like to add a simple auth using an ajp13 attribute - it'll be
far from the ajp14 md5 auth, but as good as ajp12, so we'll be able with
jk_15 to have a single connector ( ajp12 is required in 33 for shutdown ), and
possibly use it in addition/instead of the current 4.x shutdown command.
( ajp13 is already able to handle shutdown, but that feature is disabled )


This is the short term plan - if you agree I would like to get the first
betas as soon as possible ( to be clear - that's the current jk, with
o.a.ajp replaced with o.a.jk - the native side remains the same ).


For the C side, I'm working on JNI worker as a channel - that will resolve
some of the current problems in jni ( performance, i18n, etc) and will
make the jni channel available in 4.0 too. But we still have to update the
other server connectors, decide what we want to do about config, etc - so
it'll take more time.
The new C connector should be perfectly interoperable with the old one if
ajp13 is used, so a smooth and flexible transition is possible.


Comments, feedback, votes ?

Costin






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

Re: jk tags

[Bojan Smojver <bo...@binarix.com>]

costinm@covalent.net wrote:


> I would also like to add a simple auth using an ajp13 attribute - it'll be
> far from the ajp14 md5 auth, but as good as ajp12, so we'll be able with
> jk_15 to have a single connector ( ajp12 is required in 33 for shutdown ), and
> possibly use it in addition/instead of the current 4.x shutdown command.
> ( ajp13 is already able to handle shutdown, but that feature is disabled )


This sounds pretty good. Makes the whole configuration even simpler.

Bojan


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

Re: jk tags

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

> On Wed, 23 Jan 2002, Remy Maucherat wrote:
>
> > I'm sure the new HTTP/1.1 which uses similar techniques is going to be
way
> > faster too :)
>
> :-)
>
> Speaking of that, could we share the same o.a.t.u.http.BaseRequest object
> too ? This weekend I took a look at coyote, it's pretty nice !

We had a disagreement on that last time, because I think the
Request/Response should be final, and wrapping should be used instead of
extending the object.

The HTTP/1.1 should be way better and a LOT cleaner than the current one.
I'd say the stack is currently alpha quality (it passes all sorts of nasty
HTTP/1.1 pipelining tests). Of course, without the adapter for Catalina,
it's not very useful ;-)

> > What is org.apache.catalina.jk ?
> > It looks redundant with o.a.jk.server.tomcat40. It also didn't build
until
> > my commit yesterday. Should it be removed ?
>
> Yes, I think it should - the problem was that catalina doesn't load
> 'trusted' servlets unless their name starts with o.a.catalina. I was
> trying to get the jk webapp to work like admin/ and manager/, and have the
> servlet initialize all the stuff, etc ( that's how the 3.3 version works,
> interceptors.xml is no longer needed ).
>
> But I had absolutely no luck with the class loader and all kind of other
> problems - I prefer to not comment on that too much :-), so I'm back to
> Connector interface and requiring the user to copy the files in lib.
>
> If someone smarter wants to give it a try - the files will remain in
> Attic ( but for 4.1 maybe this restriction can be removed - having an app
> 'trusted' and implementing a defined interface should be enough,
> requiring o.a.c prefix doesn't add any extra security ).

It should waork better and / or should be easy to fix in 4.1. 4.0 doesn't
have support for priviledged webapps, and I haven't been sucessful at
hacking in the support without introducing significant unwanted changes at
the same time.

Remy


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

Re: jk tags

[co...@covalent.net]

On Wed, 23 Jan 2002, Remy Maucherat wrote:

> I'm sure the new HTTP/1.1 which uses similar techniques is going to be way
> faster too :)

:-)

Speaking of that, could we share the same o.a.t.u.http.BaseRequest object
too ? This weekend I took a look at coyote, it's pretty nice !

> What is org.apache.catalina.jk ?
> It looks redundant with o.a.jk.server.tomcat40. It also didn't build until
> my commit yesterday. Should it be removed ?

Yes, I think it should - the problem was that catalina doesn't load
'trusted' servlets unless their name starts with o.a.catalina. I was
trying to get the jk webapp to work like admin/ and manager/, and have the
servlet initialize all the stuff, etc ( that's how the 3.3 version works,
interceptors.xml is no longer needed ).

But I had absolutely no luck with the class loader and all kind of other
problems - I prefer to not comment on that too much :-), so I'm back to
Connector interface and requiring the user to copy the files in lib.

If someone smarter wants to give it a try - the files will remain in
Attic ( but for 4.1 maybe this restriction can be removed - having an app
'trusted' and implementing a defined interface should be enough,
requiring o.a.c prefix doesn't add any extra security ).

Costin


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

Re: jk tags

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

> Hi,
>
> Could we add a second tag - jk_14 ( assuming everyone agrees with this
> numbering scheme and doesn't propose something better ) ?

Yes, of course we can.

> I would also like to propose a different plan for jk2 - I'm still working
> on the details, but I would like to split it in smaller ( and faster
> ) steps.
>
> The first step would be a jk_15 release using the new, refactored java
> code and the current C modules. It'll be a bit faster ( I don't have
> numbers yet - but now the 4.0 connector is doing a lot more recycling and
> is using the very efficient B2C converter from 3.3 ), it'll have the
> webapp packaging ( like admin/, manager/ in 4.0, and modules/ in 3.3 ).
> From developer point of view it'll have a lot more flexibility and I hope
> it'll be cleaner.

I'm sure the new HTTP/1.1 which uses similar techniques is going to be way
faster too :)

What is org.apache.catalina.jk ?
It looks redundant with o.a.jk.server.tomcat40. It also didn't build until
my commit yesterday. Should it be removed ?

> I would also like to add a simple auth using an ajp13 attribute - it'll be
> far from the ajp14 md5 auth, but as good as ajp12, so we'll be able with
> jk_15 to have a single connector ( ajp12 is required in 33 for shutdown ),
and
> possibly use it in addition/instead of the current 4.x shutdown command.
> ( ajp13 is already able to handle shutdown, but that feature is disabled )
>
>
> This is the short term plan - if you agree I would like to get the first
> betas as soon as possible ( to be clear - that's the current jk, with
> o.a.ajp replaced with o.a.jk - the native side remains the same ).
>
>
> For the C side, I'm working on JNI worker as a channel - that will resolve
> some of the current problems in jni ( performance, i18n, etc) and will
> make the jni channel available in 4.0 too. But we still have to update the
> other server connectors, decide what we want to do about config, etc - so
> it'll take more time.
> The new C connector should be perfectly interoperable with the old one if
> ajp13 is used, so a smooth and flexible transition is possible.
>
>
> Comments, feedback, votes ?

+1.

Remy


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