You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Alex Chaffee <gu...@edamame.stinky.com> on 2000/08/19 17:27:43 UTC

some mod_jk questions/proposals

1.  Is there a reason why mod_jk is not included in the dist build?
As far as I can see it's pretty stable.  Even if we don't get to
generate binaries, it'd be nice if the source were available in the
standard download so people don't have to figure out CVS etc. in order
to build it.


2.  I wrote a shell script to build and install mod_jk using apxs.  It
basically just sets some variables and calls apxs.  Since there are
issues with Makefiles (they're hard to read; they're not very
cross-platform, e.g. FreeBSD), are there any objections to

 (a) including the build shell script in the source tree as
src/native/apache1.3/build-unix.sh

 (b) deleting the Makefile.linux and Makefile.freebsd so people like
me don't get confused (assuming the shell script works OK)

The only real advantage to make is that it allows incremental
compiling, but since the source is so small (takes about 15 seconds to
build on my Pentium 200), I don't see this as a big issue.


3. The organization of the native directory is a little weird; we have

  apache (empty except for subdirectories, of which only jserv is not empty)
  apache/jserv
  apache/connectors (empty)
  apache/modules (empty)
  apache1.3/  (containing mod_jk makefile and checked-in .o files (??))
  apache2.0/  (also containing mod_jk makefile and checked-in .o files (??))
  jk/ (containing mod_jk source)

So, three top-level directories for mod_jk, and a buried subdirectory
for jserv.

Any objection to reorganizing this to

  src/native/mod_jserv  (jserv source code)
  src/native/mod_jk  (jk source code)
  src/native/mod_jk/apache1.3  (containing 1.3-specific files if necessary)
  src/native/mod_jk/apache2.0  (containing 2.0-specific files if necessary)

If someone can manipulate the files on locus, we could do this while
keeping the revision history intact.

Only problem is, the empty directories would (might) still exist :-( 


Cheers -

 - Alex

-- 
Alex Chaffee                       mailto:alex@jguru.com
jGuru - Java News and FAQs         http://www.jguru.com/alex/
Creator of Gamelan                 http://www.gamelan.com/
Founder of Purple Technology       http://www.purpletech.com/
Curator of Stinky Art Collective   http://www.stinky.com/

Reading Certificate Information

Posted by Derek DeMoro <dd...@home.com>.
Hi All,
    I have all of the SSL pieces working fine, but have a simple question
I'm hoping one
of you can answer.  How can you actually read the certificate information?
I don't see
where I'm able to retrieve the SSLSession object.

Thanks,
Derek



Re: some mod_jk questions/proposals

Posted by "Pier P. Fumagalli" <pi...@apache.org>.
Costin Manolache wrote:
> 
> I had no problem understanding the code, I think Gal did a great
> job writing clean ( self-documenting) code.
> 
> ( I'm talking about the C side - thread pooling is a bit harder :-)

I feel like a moron... But after 2 years after stopping using C I am
writing public static void main(String argv[]) instead of int main(int
argc, char *argv[]); :) :) :)

	Pier

Re: some mod_jk questions/proposals

Posted by Costin Manolache <cm...@yahoo.com>.
"Pier P. Fumagalli" wrote:

> Costin Manolache wrote:
> >
> > Alex Chaffee wrote:
> >
> > > 1.  Is there a reason why mod_jk is not included in the dist build?
> > > As far as I can see it's pretty stable.  Even if we don't get to
> > > generate binaries, it'd be nice if the source were available in the
> > > standard download so people don't have to figure out CVS etc. in order
> > > to build it.
> >
> > No time for that - I think mod_jk is in a much better shape than
> > mod_jserv. The AJP13 is much faster and has a lot more
> > features.
> >
> > IT would be nice to make at least few binaries available.
>
> The only problem is that there are no documents on the structure of
> mod_jk and expecially ajp v13. I believe that's the key for a
> maintainable C code (and that's what I did when I was involved in the
> development of mod_jserv)... Too bad it's not the status right now...

I had no problem understanding the code, I think Gal did a great
job writing clean ( self-documenting) code.

( I'm talking about the C side - thread pooling is a bit harder :-)

Costin




Re: some mod_jk questions/proposals

Posted by "Pier P. Fumagalli" <pi...@apache.org>.
Costin Manolache wrote:
> 
> Alex Chaffee wrote:
> 
> > 1.  Is there a reason why mod_jk is not included in the dist build?
> > As far as I can see it's pretty stable.  Even if we don't get to
> > generate binaries, it'd be nice if the source were available in the
> > standard download so people don't have to figure out CVS etc. in order
> > to build it.
> 
> No time for that - I think mod_jk is in a much better shape than
> mod_jserv. The AJP13 is much faster and has a lot more
> features.
> 
> IT would be nice to make at least few binaries available.

The only problem is that there are no documents on the structure of
mod_jk and expecially ajp v13. I believe that's the key for a
maintainable C code (and that's what I did when I was involved in the
development of mod_jserv)... Too bad it's not the status right now...

	Pier (trying to work on those stuff!)

tomcat-apache-howto, WAS RE: some mod_jk questions/proposals

Posted by "Rob S." <rs...@home.com>.
So do I drop the JServ section(s) and replace with JK?

- r


Re: some mod_jk questions/proposals

Posted by Costin Manolache <cm...@yahoo.com>.
Alex Chaffee wrote:

> 1.  Is there a reason why mod_jk is not included in the dist build?
> As far as I can see it's pretty stable.  Even if we don't get to
> generate binaries, it'd be nice if the source were available in the
> standard download so people don't have to figure out CVS etc. in order
> to build it.

No time for that - I think mod_jk is in a much better shape than
mod_jserv. The AJP13 is much faster and has a lot more
features.

IT would be nice to make at least few binaries available.


> 2.  I wrote a shell script to build and install mod_jk using apxs.  It
> basically just sets some variables and calls apxs.  Since there are
> issues with Makefiles (they're hard to read; they're not very
> cross-platform, e.g. FreeBSD), are there any objections to
>
>  (a) including the build shell script in the source tree as
> src/native/apache1.3/build-unix.sh

+1

>  (b) deleting the Makefile.linux and Makefile.freebsd so people like
> me don't get confused (assuming the shell script works OK)

-0 - maybe someone will see them and will take the time to fix
them. Or maybe an ant "cc" task will be written ?


> 3. The organization of the native directory is a little weird; we have
> Any objection to reorganizing this to
>
>   src/native/mod_jserv  (jserv source code)
>   src/native/mod_jk  (jk source code)
>   src/native/mod_jk/apache1.3  (containing 1.3-specific files if necessary)
>   src/native/mod_jk/apache2.0  (containing 2.0-specific files if necessary)

+1

Please add mod_jk/aol too, there is a patch and we should check it in.
The common code should be in src/native/mod_jk/common or something.

BTW, if we're doing this reorg we can also move it up one level (
jakarta-tomcat/native/mod_jserv, mod_jk ...).
I plan to add a small .so file to change the user id ( so you can
start tomcat on 80 as root, and it'll change the id to nobody ). It's
easy to do, but need the time. There are few other enhancements
in this area - I guess 3.4 will see most of that.


> If someone can manipulate the files on locus, we could do this while
> keeping the revision history intact.

I think we can just remove and add, hacking CVS is dangerous.


> Only problem is, the empty directories would (might) still exist :-(

cvs update -d -P

Costin


Re: some mod_jk questions/proposals

Posted by Alex Chaffee <gu...@edamame.stinky.com>.
On Fri, Aug 25, 2000 at 09:34:19AM -0700, Alex Chaffee wrote:
> OK, with two +1s and no objections, I'll start to reorg the code on my
> machine.  With any luck I'll check it in soon.
> 

Done. 

I think I may have been a little overzealous in my reorg: now there's
a different ambiguity: code for connecting to netscape and iis is
under the mod_jk directory, but technically that isn't mod_jk but some
other use of the jk code.  Maybe it should have been called "jk" after
all.  Is it worth the effort to rename it?  (We can probably wait
until it gets its own CVS module.)

At any rate, except for the above, it makes more sense now.  Please
test it in your configuration (I only have the ability to compile on
Linux/Apache) and let me know if it breaks.

Also, the dist will include the full contents of the src/native
directory, so people can build mod_jk/mod_jserv without having to
figure out CVS.

 - Alex

P.S. do "cvs update -fdRP" to make sure the now empty directories get
deleted on your system.  Hmmm... can we make the release build process
do this too? I'm not sure how that works.

-- 
Alex Chaffee                       mailto:alex@jguru.com
jGuru - Java News and FAQs         http://www.jguru.com/alex/
Creator of Gamelan                 http://www.gamelan.com/
Founder of Purple Technology       http://www.purpletech.com/
Curator of Stinky Art Collective   http://www.stinky.com/

Re: some mod_jk questions/proposals

Posted by cm...@yahoo.com.
"Pier P. Fumagalli" wrote:

> Great... And when you're done, if you want to send me the list of files
> and how those have been moved, I might move them on locus without
> loosing the revision history.

Moving the files is very dangerous - if someone tries to get an
older version ( to build 3.2 or 3.1  for example) he'll not get
the right files ( at least that was my experience with moving
files in cvs).

If you copy the files it may work - when they get the older
snapshots some files will be duplicated.

I think the history of a file is less important than beeing able
to build historic versions.

Costin




Re: some mod_jk questions/proposals

Posted by "Pier P. Fumagalli" <pi...@apache.org>.
Paul Speed wrote:
> 
> "Pier P. Fumagalli" wrote:
> >
> > Great... And when you're done, if you want to send me the list of files
> > and how those have been moved, I might move them on locus without
> > loosing the revision history.
> 
>         Slightly off topic... but we used to do this for our projects.
> The problem is that you have to be kind of careful I guess.  We needed
> to branch an old revision and found out that we couldn't because files
> that we manually moved required source changes in Makefiles and other
> files.  We forever lost the ability to recreate source snapshots of
> prior to the move.  Now we always remove and re-add... we just make
> sure the initial comment mentions the old file.  An imperfect solution
> at best.
> 
>         I really wish that CVS had a move semantic.  Oh well, it may
> not have as much impact on this C code as it would on Java code.

Good point... And also Alex changed something in the sources for the
files, so, I'm just leaving things as they are in the repository...

	Pier

Re: some mod_jk questions/proposals

Posted by Paul Speed <ps...@progeeks.com>.

"Pier P. Fumagalli" wrote:
> 
> Great... And when you're done, if you want to send me the list of files
> and how those have been moved, I might move them on locus without
> loosing the revision history.

	Slightly off topic... but we used to do this for our projects.
The problem is that you have to be kind of careful I guess.  We needed
to branch an old revision and found out that we couldn't because files
that we manually moved required source changes in Makefiles and other
files.  We forever lost the ability to recreate source snapshots of
prior to the move.  Now we always remove and re-add... we just make
sure the initial comment mentions the old file.  An imperfect solution
at best.

	I really wish that CVS had a move semantic.  Oh well, it may
not have as much impact on this C code as it would on Java code.

	Just my $0.02,
	-Paul

> 
>         Pier
> 
> Alex Chaffee wrote:
> >
> > OK, with two +1s and no objections, I'll start to reorg the code on my
> > machine.  With any luck I'll check it in soon.
> >
> >  - A
> >
> > > > Any objection to reorganizing this to
> > > >
> > > >   src/native/mod_jserv  (jserv source code)
> > > >   src/native/mod_jk  (jk source code)
> > > >   src/native/mod_jk/apache1.3  (containing 1.3-specific files if necessary)
> > > >   src/native/mod_jk/apache2.0  (containing 2.0-specific files if necessary)
> > > >
> > > > If someone can manipulate the files on locus, we could do this while
> > > > keeping the revision history intact.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

Re: some mod_jk questions/proposals

Posted by "Pier P. Fumagalli" <pi...@apache.org>.
Great... And when you're done, if you want to send me the list of files
and how those have been moved, I might move them on locus without
loosing the revision history.

	Pier

Alex Chaffee wrote:
> 
> OK, with two +1s and no objections, I'll start to reorg the code on my
> machine.  With any luck I'll check it in soon.
> 
>  - A
> 
> > > Any objection to reorganizing this to
> > >
> > >   src/native/mod_jserv  (jserv source code)
> > >   src/native/mod_jk  (jk source code)
> > >   src/native/mod_jk/apache1.3  (containing 1.3-specific files if necessary)
> > >   src/native/mod_jk/apache2.0  (containing 2.0-specific files if necessary)
> > >
> > > If someone can manipulate the files on locus, we could do this while
> > > keeping the revision history intact.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

Re: some mod_jk questions/proposals

Posted by Alex Chaffee <gu...@edamame.stinky.com>.
OK, with two +1s and no objections, I'll start to reorg the code on my
machine.  With any luck I'll check it in soon.

 - A

> > Any objection to reorganizing this to
> > 
> >   src/native/mod_jserv  (jserv source code)
> >   src/native/mod_jk  (jk source code)
> >   src/native/mod_jk/apache1.3  (containing 1.3-specific files if necessary)
> >   src/native/mod_jk/apache2.0  (containing 2.0-specific files if necessary)
> > 
> > If someone can manipulate the files on locus, we could do this while
> > keeping the revision history intact.

Re: some mod_jk questions/proposals

Posted by "Pier P. Fumagalli" <pi...@apache.org>.
Alex Chaffee wrote:
> 
> 3. The organization of the native directory is a little weird; we have
> 
>   apache (empty except for subdirectories, of which only jserv is not empty)
>   apache/jserv
>   apache/connectors (empty)
>   apache/modules (empty)
>   apache1.3/  (containing mod_jk makefile and checked-in .o files (??))
>   apache2.0/  (also containing mod_jk makefile and checked-in .o files (??))
>   jk/ (containing mod_jk source)
> 
> So, three top-level directories for mod_jk, and a buried subdirectory
> for jserv.
> 
> Any objection to reorganizing this to
> 
>   src/native/mod_jserv  (jserv source code)
>   src/native/mod_jk  (jk source code)
>   src/native/mod_jk/apache1.3  (containing 1.3-specific files if necessary)
>   src/native/mod_jk/apache2.0  (containing 2.0-specific files if necessary)
> 
> If someone can manipulate the files on locus, we could do this while
> keeping the revision history intact.

Yep... I agree... That part of Tomcat is really wild. Also if we
consider the utility native code to start Tomcat as an NT service (for
example!).

	Pier