Re: JK 1.2.15 Release plan?

2005-09-28 Thread Henri Gomez
+0 go for 1.2.15

2005/9/27, Rainer Jung <[EMAIL PROTECTED]>:
> I encourage you for voting 1.2.15 as stable.
>
> Mladen Turk wrote:
>
> > Anyhow, I would like that we vote this (1.2.15) version as stable,
> > because it's a bug-fix release over the 1.2.14 stable.
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [VOTE] JK 1.2.15

2005-09-30 Thread Henri Gomez
Well the build on iSeries failed :

/home/apache/jk/native/apache-2.0/mod_jk.c, 86.10: CZM0296(30) £include
  file "unixd.h" not found.
/home/apache/jk/native/apache-2.0/mod_jk.c, 2437.10: CZM0304(10) No
  function prototype given for "unixd_set_global_mutex_perms".


Should add in mod_jk.c line 78 (I still can't commit on jtc )

# if !defined(OS2) && !defined(WIN32) && !defined(BEOS) &&
!defined(NETWARE) && !defined(AS400)

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [VOTE] JK 1.2.15

2005-09-30 Thread Henri Gomez
BTW, after I added the && !defined(AS400), jk builded and works right now.

So it's stable for me

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [VOTE] 5.5.12 Stability

2005-10-03 Thread Henri Gomez
Stable for me

2005/10/3, Yoav Shapira <[EMAIL PROTECTED]>:
> Hi,
> Tomcat v5.5.12 has been out for a little more than a week now, so hopefully
> we've had time to test it.  Please let us know what you think of its stability
> below.  If anyone with the proper license could run the Servlet (v2.4) and JSP
> (v2.0) TCK tests on Tomcat 5.5.12, that would be great as well.  Thank you.
>
> Tomcat 5.5.12 is:
> [ ] Stable - no major issues,
> [ ] Beta - at least one major issue: what is it?
> [ ] Alpha - multiple things or a real showstopper: please provide details..
>
> Yoav
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [VOTE] JK 1.2.15

2005-10-03 Thread Henri Gomez
well unixd.h is not on the iSeries, at least V5R3 (the latest)

2005/10/1, Jean-frederic Clere <[EMAIL PROTECTED]>:
> Henri Gomez wrote:
>
> >Well the build on iSeries failed :
> >
> >/home/apache/jk/native/apache-2.0/mod_jk.c, 86.10: CZM0296(30) £include
> >  file "unixd.h" not found.
> >/home/apache/jk/native/apache-2.0/mod_jk.c, 2437.10: CZM0304(10) No
> >  function prototype given for "unixd_set_global_mutex_perms".
> >
> >
> >Should add in mod_jk.c line 78 (I still can't commit on jtc )
> >
> ># if !defined(OS2) && !defined(WIN32) && !defined(BEOS) &&
> >!defined(NETWARE) && !defined(AS400)
> >
> >
> Not very good... We should detect  unixd.h.
>
> >-
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
> >
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Tomcat 5.5.12 / Jasper2 -> showstoppers ?

2005-10-04 Thread Henri Gomez
Hi to all,

I don't know if they should be considered showstopper but while
playing with 5.5.12 for some of our new applications, I see these
problems :

When using Jasper2 in JSP precompilation step, it load needed taglibs
jars defined in web.xml, but didn't release all of them after build
(here is how it's invoked)




As such, when you're using ANT from eclipse and you specify ANT should
use the same JRE as the workspace, you're puzzled and should restart
eclipse ;-(


Another serious problem in Jasper2 precompilation is when web.xml
contains external entites living in the webapp. We fixed Jasper2 in
5.5.9 to fixe this behaviour at runtime, but it appears it's also
needed in precompilation step.

Here is a sample web.xml where you could see use of entities located
in base.xml and jsp.xml (also located in WEB-INF).




http://java.sun.com/dtd/web-app_2_3.dtd"; [





]>



...

&base;
&jsp;

...

  
http://jakarta.apache.org/taglibs/random-1.0
/WEB-INF/lib/taglibs-random.jar
  

  


Did these bugs are showstoppers or should they be postponed to 5.5.13 ?

Regards

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Tomcat 5.5.12 / Jasper2 -> showstoppers ?

2005-10-05 Thread Henri Gomez
> > When using Jasper2 in JSP precompilation step, it load needed taglibs
> > jars defined in web.xml, but didn't release all of them after build
> > (here is how it's invoked)
>
> Does this mean JARs are locked ?

yes, and since ant is running on the eclipse JVM, no other way to
release the jar that to stop eclipse ;(

> > Another serious problem in Jasper2 precompilation is when web.xml
> > contains external entites living in the webapp. We fixed Jasper2 in
> > 5.5.9 to fixe this behaviour at runtime, but it appears it's also
> > needed in precompilation step.
>
> I actually forgot what the fix was.

If I recall exactly in JspConfig :

private void processWebDotXml(ServletContext ctxt) throws JasperException {

InputStream is = null;

try {
URL uri = ctxt.getResource(WEB_XML);
if (uri == null) {
// no web.xml
return;
}

is = uri.openStream();
InputSource ip = new InputSource(is);
ip.setSystemId(uri.toExternalForm());

ParserUtils pu = new ParserUtils();
TreeNode webApp = pu.parseXMLDocument(WEB_XML, ip);

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [VOTE] 5.5.12 Stability

2005-10-06 Thread Henri Gomez
Should we post-pone to 5.5.13 the fixes to Jasper2 ?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [ANNOUNCE] Tomcat 4.0 Milestone 3

2000-10-27 Thread Henri Gomez

> I found a bug at the last minute (while constructing the "m3"
> distribution
> bundles) that Tomcat 4.0 croaks (with the error you quote below) if you
> place a
> WAR file of the application into the webapps directory, *and* you
> mention this
> application in a  element in server.xml.  This combination can
> easily
> happen with the examples application.

Ok, I was asking myself what I've missed ;-(

> The workaround for now is to leave the application unpacked in the
> distribution
> -- that's what I had to do with m3, which is why the downloads were so
> much
> bigger.  The underlying bug will be fixed before the next milestone.

I'll modify my RPM to include a expanded examples webapps or to comment the 
examples part in server.xml. I could also apply a patch in my RPM to current 
m3, just tell me what ...

RPM for tomcat 4.0 is at http://rpmized.free.fr/rpms/tomcat4/

-
Unix is like a tipi -- no Gates, no Windows, and an Apache inside.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: No revolution today

2000-11-08 Thread Henri Gomez

> It is important that tomcat3 has a design that allows support for
> future
> versions of the servlet API, but if tomcat developers don't want to see
> it
> happen - so be it. When Servlet2.3 will be final and in wide use, there
> is
> nothing that can stop someone from providing the module that supports it
> (
> not necesarily from apache site ). 

Many of us could live with a bullet proof TC 3.3 with API 2.2/JSP 1.1 for at 
least one or two years. Note that many importants sites still use Apache JServ 
(API 2.0) and GnuJSP. 

> But for now it's important to continue to improve the foundation. 
> 
> 
> My focus will continue to be on Tomcat3.3, in fixing the encoding
> problems and on improving the performance. We are not yet the best
> servlet container - so there is still work to do.

> If you believe that tomcat3 can't be the best container, and a
> different
> model is better suited for that - that's perfect, as long as the code
> you
> write is reusable everyone will benefit. And I'm sure the users will
> choose whatever it's better for them, regardless of version
> numbers. It's open source - and so far the better code has survived
> regardless of politics.

Yes, TC 3.3 must fix TC 3.2 bugs and boost performances. Users could allways 
bench TC 3.3 vs TC 4.0 or others servlets engines. And they'll choose their 
favorite


> The rules are still there - after a release, the main branch is open
> for
> the development of the next release, and as long as we are improving I
> don't think anyone can stop the evolution. 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




RE: No revolution today

2000-11-09 Thread Henri Gomez

En réponse à Paulo Gaspar <[EMAIL PROTECTED]>:

> But at the moment, for me, my company and people/companies I know, the
> ONE
> main priority is having a fast and robust Servlet Engine - with robust
> being the priority.

+1

> Your focus on a modular architecture keeps all doors open for the
> development of new features. IMO, a robust, fast enough and easily
> extensible Servlet Engine would take the market.

+2

> We do NOT necessarily depend on a engine that is the "reference
> implementation of..." and that has hundreds of features.
> 
> We depend on a engine we can use on production sites.

+3

PS: I'd like to see that I'm not the only one worried about quality and 
production use ;-$

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: [MY_OPINION] Tomcat 3.x

2000-12-18 Thread Henri Gomez

> Ok, so you are going to stop at 3.3 and then what? Abandon things? Hope
> that
> others pick things up? Move to Catalina? What are you going to do?

Costin said he will continue to maintain the 3.3 base. But I think is that 
after such objections, he will not start a 3.4 tree (at least not under Apache 
Umbrella)

> Tomcat 3.x or 4.x? That is the confusion that needs to be cleared up.

The confusion will exist also for Apache 1.3 / 2.0. And this one will be much 
more important.

> The point being that you are duplicating effort. The code is already in
> the future version and now you are back porting it to the past. Why is that
> good?

Again it's not a duplicate effort since differents persons works on different 
projects on the /+- same need : a Free Servlet Engine.
 
> Why is that effort good if people will be moving to 4.x anyway?

You do the judge there. Everybody must go to TC 4.0 ? Who decide that ?

> When the future is 4.x?

The near future is still TC 3.x and it may be a race between TC 3.3 BETAS and 
TC 4.0 BETAS. It will be a sane emulation.

> Sure, it is good. I'm not doubting that fact. The reality though is that
> we are moving away from Tomcat 3.x to 4.x.

Again not everybody is ready to go from 3.x to 4.x. I'd like the TC 4.0 design 
but it seems to do just to many things. JMX, differents JAXP (lib/server).

> > Better design :-) ? Continuity ?
> 
> In your opinion.

The users will decide. Be fair, let them evaluate TC 3.3. 

> > I think tomcat 3.x has most of the features that I
> > wanted - I would be happy to see 4.0 using the same
> > patterns and design that allow high performance, but I
> > don't have the time or wish to do it again.
> 
> That you wanted. What about what other people want? What about what is
> good for the overall project? Your thinking is very singular.

The overall project is TC 4.0 but TC 3.3 is Costin effort to continue a 3.x 
branch. A Future to existing installed site. And as I said before a fast&ligth 
servlet-engine (TC 3.3) against a full featured servlet engine (TC 4.0)

> > It's funny you're telling this as if I'm doing
> > something wrong or forking - I strongly agree that
> > forking is bad, and so far I did all I could to avoid
> > forks ( i.e. I stoped developing the Servlet2.3 module
> > as part of tomcat3.3, etc).
> 
> > It's the second time an Apache member is asking me to
> > go somewhere else. Believe me, right now it's my
> > biggest wish - I've had more than enough !
> 
> I will repeat myself again, since you didn't get it the first time.
> Sigh.

You're just too hard here.

Must we go to vote to see who want Costin stay and who want him stay ?
Could Apache Group could afford to let talentuous developper working on complex 
projects fly elsewhere ?

It's seems clear there is scission between pro 3.x and 4.x.

Why not give Costin the 3.x tree responsability (From 3.2.2 to 3.) ?

It will let Craig and others Suners (that's the reality) be fully operationnal 
on TC 4.x tree (and most of them are paid for). This way more time will be 
freed to conduct the TC 4.0 project.

We didn't need a tomcat war OR even worth have Costin and TC 3.3 fly to 
sourceforge. 

Everybody agreed is does a fantastic works (with limited time and resource). 
Having alternative on the same organisation is not a restriction but give more 
freedom to final users.

Some will follow TC 4.0 since it will be J2EE, others will develop modules for 
TC 3.3 and find it well suited for their need. 

There will be Apache 1.3.x and Apache 2.0 sites around the world for many time.
Why not TC 3.x and 4.x ?

What I see is not a question of resource split (if Apache decided to stop TC 
3.3 Costin and possiby others will certainly go elsewhere), but a 

I'd like to see what Craig think about giving Tomcat TC 3.x to Costin.
Or why not create a new project, HellCat, starting with TC 3.3 code base and 
which will be the REFERENCE IMPLEMENTATION of SERVLET 2.2 / JSP 1.1 .




Re: FW: mod_jk2

2002-07-04 Thread Henri Gomez

Quoting Pier Fumagalli <[EMAIL PROTECTED]>:

> Fyi...  Not acked...

Just replied to this gentleman :)

Asked to stay tuned and watch announcement on tomcat-dev
for mod_jk 1.2.0 and 2.0.0 alpha.

Henri

> 
> -- Forwarded Message
> From: Mark Howell <[EMAIL PROTECTED]>
> Date: Thu, 4 Jul 2002 02:51:24 -0500 (CDT)
> To: <[EMAIL PROTECTED]>
> Subject: mod_jk2
> 
> Hello,
> 
> The past two days, I have attempted to download mod_jk2 from
> http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk2/release/
> and every time that I checked, the server suggested an empty directory
> structure.  There is, under the nightly builds directory, mod_jk2 dll's
> for M$, but I'm looking for the Apache mod_jk2.
> 
> Giving up on mod_jk2, I proceeded to try to get mod_jk instead, but found:
> http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.1
> /bin/linux/i386/
> to be empty as well.  So...then I figured I would just build it from
> source, but:
> http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.1
> /src/
> was empty as well.
> 
> TIA,
> Mark
> [EMAIL PROTECTED]
> 
> 
> 
> 
> 
> -- End of Forwarded Message
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
> 
> 




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: [VOTE] Apache Tomcat 5.0 Proposal

2002-07-08 Thread Henri Gomez


> As long as the interfaces don't change too much (especially, Container and
> Component, all the rest I don't care). We started out process of stripping
> out "for good" all the stuff distributed with TC4x, working on some new
> startup classes and so on (and looking over at the excellent work made by
> MinTC, and what Scarab is doing on that front)...
> 
> If you want to be flamed heavily check out 

Welcome to Jerry ;)

BTW, emulation is allways great till it didn't turn in flam wars.

I'll try to track both TC 5.0 and Jerry 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




jspc - more patch

2002-07-08 Thread Henri Gomez

Hi to all,

A coworker found some more problems with jspc encoding and
provided the attached patch for 3.3.1.

Thanks to take a look and apply (didn't have access to 
cvs via ssh for now).

Regards

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: jspc - more patch

2002-07-08 Thread Henri Gomez

Quoting Henri Gomez <[EMAIL PROTECTED]>:

Oups, attachment missing :

> Hi to all,
> 
> A coworker found some more problems with jspc encoding and
> provided the attached patch for 3.3.1.
> 
> Thanks to take a look and apply (didn't have access to 
> cvs via ssh for now).
> 
> Regards
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
> 
> 
> 





Index: org/apache/jasper/compiler/CharDataGenerator.java
===
RCS file: 
c:/data/cvs/jakarta-tomcat-3.3.1/org/apache/jasper/compiler/CharDataGenerator.java,v
retrieving revision 1.1
diff -u -r1.1 CharDataGenerator.java
--- org/apache/jasper/compiler/CharDataGenerator.java   5 Jul 2002 10:20:22 -  
 1.1
+++ org/apache/jasper/compiler/CharDataGenerator.java   8 Jul 2002 11:07:35 -
@@ -123,7 +123,7 @@
sb.append("\\t");
break;
default:
-   sb.append((char) ch);
+   this.writeChar((char) ch, sb);
}
}
writer.print(sb.toString());
@@ -131,6 +131,18 @@
writer.println();
 }
 
-
+protected void writeChar( char c, StringBuffer buf ) {
+if ( c < 128 )
+   // if char is pure ASCII -> write it
+buf.append( c );
+else {
+// if char isn't pure ASCII -> write it's unicode
+buf.append( "\\u" );
+String hexa = Integer.toHexString( c );
+for( int i = hexa.length() ; i < 4 ; i++ )
+buf.append( '0' );
+buf.append( hexa );
+}
+}
 
 }
Index: org/apache/jasper/compiler/MappedCharDataGenerator.java
===
RCS file: 
c:/data/cvs/jakarta-tomcat-3.3.1/org/apache/jasper/compiler/MappedCharDataGenerator.java,v

retrieving revision 1.1
diff -u -r1.1 MappedCharDataGenerator.java
--- org/apache/jasper/compiler/MappedCharDataGenerator.java 5 Jul 2002 10:20:24 
-   1.1
+++ org/apache/jasper/compiler/MappedCharDataGenerator.java 8 Jul 2002 11:07:35 
+-
@@ -113,7 +113,7 @@
sb.append("\\t");
break;
default:
-   sb.append((char) ch);
+   this.writeChar((char) ch, sb);
}
}
writer.print(sb.toString());


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>


Re: [ANNOUNCEMENT] Tomcat 4.1.7 Beta

2002-07-09 Thread Henri Gomez

RPM are currently in works, stay tuned :)

> Tomcat 4.1.7 Beta has been released. It includes major bugfixes and 
> improvements over the previous Tomcat 4.1.3 Beta (please refer to the 
> release notes for the complete list).


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: Jetty and mod_jk2

2002-07-09 Thread Henri Gomez

> > I agree with Remy the jetty-specific docs should go with jetty. 
> 
> Fair enough. Perhaps a pointer to where to find these docs might not
> go amiss, though?

We could add an URL in documentation to jetty HOW-TO.

> > For the native code - I think we can add specific instructions or 
> > direct to the right place.
> 
> That would be great. If the "right place" is the README.txt, I'll
> happily try and spanner in the relevant information.

Do it, at least for jk 1.2.0, but where to put it ?
I think we need a README.txt in jtc/jk with misc information about
jk (1.2.0), and there we could put jetty ref.

> > BTW, it may be a good idea for jetty to take a look at the 
> > java side of ajp as well, there are some interesting features. 
> > Coyote is quite flexible, and I'm sure it would be easier to 
> > adapt it to jetty and take advantage of all jk2 features.
> 
> What would be involved in this? I'm starting to get itchy, and though
> I've not got much free time atm, in a few weeks things should be
> better I've not dabbled in the internals of tomcat or coyote yet,
> but getting in there and seeing how bits work together is the best way
> that I know of to become aquainted with something. Any pointers,
> please?

> > And I'm looking forward to code contributions and bug fixes 
> > from jetty people. If there's anything we can do to help - 
> > please let us know. I don't see jetty as a 'competition' - 
> > and I hope they don't either. Our goal is to write a good servlet 
> > container and solve 'itches', their goal seems similar. 
> 
> I'll forward your post to some of the Jetty developers. We'll see
> where things go from there. 

I'll be very happy to see jetty dev comments on the tomcat-dev list ;)


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: [5.0] [VOTE] New branches and repositories

2002-07-11 Thread Henri Gomez

Quoting Remy Maucherat <[EMAIL PROTECTED]>:

> 
> 
> A) Servlet 2.4 & JSP 2.0 API
> 1. [X] Use new jakarta-servletapi-5
> 2. [ ] Use the HEAD of jakarta-servletapi
> 3. [ ] Other:

> B) Catalina 2.0
> 1. [X] Use new jakarta-tomcat-catalina
> 2. [ ] Use new jakarta-tomcat-5.0
> 3. [ ] Use the HEAD of jakarta-tomcat-4.0
> 4. [ ] Other:
> 
> C) Coyote 2.0
> 1. [X] Yes, use the HEAD of jakarta-tomcat-connectors
> 2. [ ] No, use:
> 
> D) Tomcat 5.0
> 1. [X] Use new jakarta-tomcat-5.0
> 2. [ ] Use the HEAD of jakarta-tomcat-4.0
> 3. [ ] Use the HEAD of jakarta-tomcat
> 4. [ ] Other:
> 
> E) Jasper 2.0
> 1. [X] Yes, use the HEAD of jakarta-tomcat-jasper
> 2. [ ] No, use:
> 
> 

Which make Tomcat 5.0 a glue for edge packages (I feel it more modular)
 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




TC 4.1.7 write access on config dir

2002-07-15 Thread Henri Gomez

While packaging tomcat 4.1.7 rpm, and trying to make it as secure as
possible with tomcat running as tomcat4:tomcat4 and owning log/work/temp dir),
I see that it tries to write on conf/tomcat-users.xml.new or conf/jk2.properties,
and to mimic apache httpd server conf is owned by root and in read-only mode.

Any ideas to fix that ?



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




RE: [PROPOSAL] Split the repo's

2002-07-18 Thread Henri Gomez

Quoting "Ignacio J. Ortega" <[EMAIL PROTECTED]>:

> > De: Jon Scott Stevens [mailto:[EMAIL PROTECTED]]
> > Enviado el: 18 de julio de 2002 1:34
> 
> > 
> > [X] I don't want the API's split into separate repo's
> > [ ] I don't care
> > [ ] I want the API's split into separate repo's.
> > 
> 
> I dont see why this needs another repo, my only reason is that there are
> too much already, but i can understand the naming problem is very
> confusing to serve 2 different apis under the name of only one of them,
> this should by changed, now that is easy..
> 
> Counterproposal:
> 
> one repo "jakarta-tomcat-apis",  this saves the naming point it's
> neutral, this could contain every api Tomcat uses for 5.0 and in future,
> branching allowed,  )
> 
> 2 dirs inside "servlet" & "jsp", standalone build.xml for each, and one
> common in the root repo dir.. to match every taste..

+1 that's a good idea ;)


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: [VOTE]: Re: cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0 mod_jk.c

2002-07-23 Thread Henri Gomez

Quoting Bojan Smojver <[EMAIL PROTECTED]>:

> And I answer (to myself :-)
> 
> On Tue, 2002-07-23 at 14:47, Bojan Smojver wrote:
> > So, the unsolved questions for me are:
> > 
> > 1. What is it then that jk_handler() does that makes it actually serve the
> > request when DIR_MAGIC_TYPE is included in the test? It must be that its
> mapping
> > is 'better' than mapping of jk_translate()...
> 
> Nothing special - it just does it ALWAYS. Which means that Tomcat ALWAYS
> gets involved, which is NOT what Bill wanted (sorry Bill) and is
> definitely not what I wanted. In order to fix that and let Apache handle
> the directories it can physically see, and give the rest to Tomcat, we'd
> need to do this at the beginning of jk_handler():
> 
> -
> /* Deciding if this request is for us, or should we pass it on */
> if(strcmp(r->handler,JK_HANDLER)){
> if(strcmp(r->handler,DIR_MAGIC_TYPE)) /* Not directory, skip */
> return DECLINED;
> else if(ap_is_directory(r->pool, r->filename)) /* Can stat, skip */
> return DECLINED;
> }
> -
> 
> Which would then mean that you MUST have DirectoryIndex in place if you
> have extension mappings and want your physically accessible files served
> by Tomcat. It would also mean that all physically accessible
> directories, without ANY index files mentioned in DirectoryIndex, would
> be served by Apache. Anything else would go to Tomcat for resolution.
> This is not ideal and maybe not even correct, but it is the best I can
> come up with at this point.
> 
> Before I make any changes to the CVS, I'd like to know what everyone
> thinks. So, here are the choices:
> 
> [ ] Keep it as is and send all DIR_MAGIC_TYPE requests to Tomcat
> [ ] Keep it as is, but only if DIR_MAGIC_TYPE can be turned on/off
> [ ] Remove DIR_MAGIC_TYPE handling altogether
> [ ] Make the change
> [ ] Make the change, but only if DIR_MAGIC_TYPE can be turned on/off
> 
> > 2. Or is it that jk_translate() never even gets involved during that
> request and
> > therefore never has the chance to do the mapping?
> 
> I answered this one before. The request with DIR_MAGIC_TYPE never
> touches jk_translate().

For someone who have all its tomcat behind a webserver, I'll be to have the
requests sent to Tomcat since my web servers won't have a directory created for
all the webapps available on tomcats farms behind.

Alternativly I don't want to receive index.php or index.pl in Tomcat, and so
want  only the one which match with JkMount (in mod_jk 1.2 way), ie JkMount
*.jsp ajp13.



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: mod_jk2

2002-07-24 Thread Henri Gomez

Quoting Dev Zero G Ltd <[EMAIL PROTECTED]>:

> Hello and thanks for reading!
> 
> Trying to build mod_jk2 for Tomcat4 and Apache2... with huge problems :( 
> Having gotten this far, I have this compile problem:
> 
> apache 2.0.39; freebsd 4.4 i386; conne4ctors 4.0.4
> 
>  snip 
> [so] In file included from 
> /usr/tmp/jakarta-tomcat-connectors-4.0.4-src/jk/native2/include/jk_env.h:71,
> [so] from 
> /usr/tmp/jakarta-tomcat-connectors-4.0.4-src/jk/native2/include/jk_pool.h:67,
> [so] from 
> /usr/tmp/jakarta-tomcat-connectors-4.0.4-src/jk/native2/common/jk_uriMap.c:73:
> [so] 
> /usr/tmp/jakarta-tomcat-connectors-4.0.4-src/jk/native2/include/jk_mutex.h:122:
> 
> syntax error before `apr_thread_mutex_t'
> 
> BUILD FAILED
> file:/usr/tmp/jakarta-tomcat-connectors-4.0.4-src/jk/native2/build.xml:276: 
> Compile failed 
> /usr/tmp/jakarta-tomcat-connectors-4.0.4-src/jk/native2/common/jk_uriMap.c
>  snip 
> 
> one of the main problems is that apache 2 installs into several 
> directories under freebsd ports, and the connector compile script 
> expects it to go into just one - apache2/ ...

There is options in the latest configure for mod_jk2 to adapt to your layout,
for example it match my apache 2.x rpm which install in many directories :)



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: [VOTE]: Re: cvs commit:jakarta-tomcat-connectors/jk/native/apache-2.0 mod_jk.c

2002-07-24 Thread Henri Gomez

> > I can live with any but the first.  It would be nice to have it as a
> config
> > option however.  JkOptions is probably fine for 1.2.  Not sure where it
> > should be set in Jk2.
> 
> Thanks. I'm not sure about mod_jk2 either. The latest reports show that
> the code still doesn't work.

Great to have it in jk 1.2.x.

BTW, what's the default behaviour ?


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: mod_jk2.so compiled (after patching), but won't install

2002-07-25 Thread Henri Gomez

Quoting Dev Zero G Ltd <[EMAIL PROTECTED]>:

> First of all - many many thanks to everybody who has helped so far - we 
> really appreciate it.. Just one last push required. :)
> 
> We finally got mod_jk2.so and libjkjni.so to compile (see patch history 
> at the bottom of the mail), but can't install. We put them into 
> $(APACHE2_HOME)/modules and $(CATALINA_HOME)/lib accordingly.
> 
> But after running $(APACHE2_HOME)/bin/apachectl configtest we get an 
> error message:
> 
> --- error start ---
> file://augada/usr/local/apache2/modules ../bin/apachectl configtest
> Syntax error on line 231 of /usr/local/apache2/conf/httpd.conf:
> Cannot load /usr/local/apache2/modules/mod_jk2.so into server:
> /usr/local/apache2/modules/mod_jk2.so: Undefined symbol
> "apr_thread_mutex_trylock"
> --- error end ---
> 
> What could it be?

Which version of Apache 2.0 did you have ?


> --- patch history start ---
> Filename: jk\native2\include\jk_mutex.h
> 
> Line #:75
> Old line  :
> #ifdef HAS_APR
> New line:
> #if APR_HAS_THREADS

+1

> #ifdef HAS_APR


> Line #:121
> Old line  :
> #ifdef APR_HAS_THREADS
> 
> New line:
> #if APR_HAS_THREADS
> 
> Reason:This conditional define statement adjusts variable
> definition (threadMutex). Type of this variable depends on define
> directive conditions, but to have needed types there are some #ifdef
> statements on lines 75-81. So, those definition statements are not
> the same, and this situation causes build-time error, when compiler
> includes one header file (with one type defined inside), but variable
> tries to have another type (found by me in another .h file - not
> included while build time due to #ifdef directives). Such changes
> were done experimentally and may be not 100% correct. In original
> compiler fails with message like "syntax error on before
> apr_thread_mutex_t in line 121"
>
apr.h have #define APR_AS_THREADS 1 so both should be the same.
Didn't have any build error with that on Linux Redhat 7.2 + apache 2.0.39 ...

> Filename jk\native2\build.xml
> 
> Line #:  374
> Action: commented
> 
> Reason   :Having this link option uncommented (original) I could
> not acquire libjkjni.so, only .a and .la files present. As far as I
> am dummy in FreeBSD C/C++, I used something
> "try-to-change-something-and-see-what-you-get" method (it has pretty
> russian idiom,but I don't know its analog in English)
> 
> Filename: jk\build.properties
> 
> Some pathes set to correspond to reality (path to apache, etc)
> 
> Filename:jk\native\apache-2.0\build-unix.sh
> 
> Line #:  44
> Action:commented.
> Line #:  46
> Action:  uncommented and approved
> New line:
> INCLUDE="-I ../common -I$APACHE_HOME/include/apr-util $JAVA_INCLUDE"

Don't use build-unix.sh but instead configure/make. The build.sh is no more
present in recent jtc cvs, deprecated in favor of autoconf/make 

> Reason:while compiling mod_jk.so compiler could not see
> connectors includes. I added first statement to make it visible
> --- patch history end ---
> 
> 
> 
> 
> 




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: mod_jk2.so compiled (after patching), but won't install

2002-07-25 Thread Henri Gomez

Quoting Dev Zero G Ltd <[EMAIL PROTECTED]>:

> > Which version of Apache 2.0 did you have ?
> 
> We are running Apache 2.0.39 on FreeBSD 4.4

good

> >>--- patch history start ---
> >>Filename: jk\native2\include\jk_mutex.h
> >>
> >>Line #:75
> >>Old line  :
> >>#ifdef HAS_APR
> >>New line:
> >>#if APR_HAS_THREADS
> > 
> > +1
> > 
> >>#ifdef HAS_APR
> > 
> > 
> >>Line #:121
> >>Old line  :
> >>#ifdef APR_HAS_THREADS
> >>
> >>New line:
> >>#if APR_HAS_THREADS
> >>
> >>Reason:This conditional define statement adjusts variable
> >>definition (threadMutex). Type of this variable depends on define
> >>directive conditions, but to have needed types there are some #ifdef
> >>statements on lines 75-81. So, those definition statements are not
> >>the same, and this situation causes build-time error, when compiler
> >>includes one header file (with one type defined inside), but variable
> >>tries to have another type (found by me in another .h file - not
> >>included while build time due to #ifdef directives). Such changes
> >>were done experimentally and may be not 100% correct. In original
> >>compiler fails with message like "syntax error on before
> >>apr_thread_mutex_t in line 121"
> >>
> > 
> > apr.h have #define APR_AS_THREADS 1 so both should be the same.
> > Didn't have any build error with that on Linux Redhat 7.2 + apache 2.0.39
> ...
> > 
> 
> our version of apr.h has #define APR_HAS_THREADS 0

So you don't have THREADS and yes #ifdef APR_HAS_THREADS is invalid,
your patch is correct

> Maybe apache/connector has not been ported properly to FreeBSD?

Linux, solaris, windows and many stranges architectures (JF ;)
patches applied to jk_mutex.h

> >>Filename jk\native2\build.xml
> >>
> >>Line #:  374
> >>Action: commented
> >>
> >>Reason   :Having this link option uncommented (original) I could
> >>not acquire libjkjni.so, only .a and .la files present. As far as I
> >>am dummy in FreeBSD C/C++, I used something
> >>"try-to-change-something-and-see-what-you-get" method (it has pretty
> >>russian idiom,but I don't know its analog in English)
> >>
> >>Filename: jk\build.properties
> >>
> >>Some pathes set to correspond to reality (path to apache, etc)
> >>
> >>Filename:jk\native\apache-2.0\build-unix.sh
> >>
> >>Line #:  44
> >>Action:commented.
> >>Line #:  46
> >>Action:  uncommented and approved
> >>New line:
> >>INCLUDE="-I ../common -I$APACHE_HOME/include/apr-util $JAVA_INCLUDE"
> > 
> > 
> > Don't use build-unix.sh but instead configure/make. The build.sh is no
> more
> > present in recent jtc cvs, deprecated in favor of autoconf/make 
> > 
> 
> will try this
> 
> > 
> >>Reason:while compiling mod_jk.so compiler could not see
> >>connectors includes. I added first statement to make it visible
> >>--- patch history end ---
> 
> Thanks again
> 
> 
> 




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: [OT] Leaving Sun

2002-07-26 Thread Henri Gomez

Quoting Remy Maucherat <[EMAIL PROTECTED]>:

> Hi all,
> 
> Warning: Off topic !
> 
> I'd like to post a quick notice about my current job situation.
> As of today, I am no longer an employee of Sun Microsystems, and I am 
> relocating in France.

Welcome back home Remy ;)

Hope to meet you one day in Savoie :)


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: Mod_jk for Apache2.

2002-07-28 Thread Henri Gomez

Quoting Bojan Smojver <[EMAIL PROTECTED]>:

> On Sat, 2002-07-27 at 02:36, Mike Anderson wrote:
> > Now that Apache 2.0 has been released, when/how should we deliver the
> > mod_jk plugin (the 1.2.0 version from jtc) for Apache 2.0.  Since the
> > magic number changes between builds, we can't put a version out there
> > that will work with all possible versions.  Should we just try and keep
> > up with the current Apache 2.0 (currently 2.0.39)?
> 
> Anything below 2.0.39 has security issues and should not be used in
> production. So, it shouldn't even be supported. 2.0.39 should be the
> starting point.

yes, and 2.0.39 is an official release, we should release a mod_jk at each 
Apache 2.0 release. And may be at one time, httpd team will no more make the 
version number matching mandatory for modules.

> > Should we update all
> > of the possible tomcat releases (currently 3.2.4, 3.3.1, 4.0.4, 4.1.7
> > Beta) when Apache updates?
> 
> I reckon that's going to be a lot of work. Unless there are security
> issues, we should focus on what's current. In other words, the current
> stable version from each branch. Anything else, build from source or use
> the old version.
> 
> If someone contributes a binary, then by all means, it should be
> published, but otherwise it shouldn't be a target.

When I'll be back from hollidays, I'll tag mod_jk 1.2.0 and release a source 
tarball. And after that I'll make the binaries for Apache 1.3 (with and without 
SSL) and Apache 2.0 for Linux (i386 and maybe also PowerPC). I think Nacho 
could produce at that time the IIS redirector, Mike netware and others Apache 
1.3/2.0 for Windows (I could take a look in making a mod_jk for cygwin).

BTW, I return to my wet paint ;[


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: Mod_jk for Apache2.

2002-07-28 Thread Henri Gomez

Quoting Bill Barker <[EMAIL PROTECTED]>:


> > > Should we update all
> > > of the possible tomcat releases (currently 3.2.4, 3.3.1, 4.0.4, 4.1.7
> > > Beta) when Apache updates?

Oups, forgot to say that mod_jk will be release in the jtc builds dir, 
(http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/)
and so will be available for ALL tomcat versions. It was one of the goal of 
jtc :)

It was discussed many times ago to drop/remove the jk support from tomcat 
repositories (at least from TC 3.3.x)


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: [VOTE] New committer: Jean-Francois Arcand

2002-08-19 Thread Henri Gomez

Quoting Patrick Luby <[EMAIL PROTECTED]>:

> I would like to propose that we add Jean-François Arcand as a Tomcat 
> committer. I believe he has submitted enough patches to show that he 
> will be a positive contributor to Tomcat 5.
> 
> Thanks,

Back from vacations (still 1100 mails to review on various list) but you got
rigth now my +1.

Welcome on board JF (hey another JF ;)

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




jtc rpms

2002-08-19 Thread Henri Gomez

Hi to all,

Many rpms users ask me for mod_jk/mod_jk2/mod_webapp rpms.

Up to now they were released in tomcat4 release rpm subdir (against the jtc
source tarball available at that time).

What about putting the mod_jk/mod_jk2/mod_webapp rpms into another location to
be sure they will not be dropped after a new tomcat 4 release is out, ie moved
to http://jakarta.apache.org/builds/jakarta-tomcat-4.0/archives/v4.0.3/rpms/

I propose to create a snapshot subdir in jtc, snapshot, and provide here the
necessary binaries, for example Linux rpms & .so, windows, netware, iis are
welcome also.

http://jakarta.apache.org/builds/jakarta-tomcat-connectors/snapshot/rpms/

We could have right now :

http://jakarta.apache.org/builds/jakarta-tomcat-connectors/snapshot/v4.1.9-beta/  
rpms/

What do you think about that ?


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: tomcat-committers mailing list

2002-11-26 Thread Henri Gomez
Martin Algesten wrote:

Just for our non-committers peace of mind, what is the purpose of this
list? What kind of "information" is it that we are to be denied or have
delayed?


Discussing for example possible security issues and resolve them
before making a public announce !



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: tomcat-committers mailing list

2002-11-26 Thread Henri Gomez
Laxmikanth M.S. wrote:

sound good


What's sounding good ?

Reporting and Fixing security problems before making them public
or "Coming together is the beginning, staying together is progress and 
working together is Success" ?

Regards
Laxmikanth M S 
Off*  : 6610330 extn 1256
Res* : 5267150
http://www.sonata-software.com


Coming together is the beginning, staying together is progress and working
together is Success


What lies behind us and what lies before us are tiny matters compared to
what lies within us  - Emerson




-Original Message-----
From:	Henri Gomez [SMTP:[EMAIL PROTECTED]]
Sent:	Tuesday, November 26, 2002 7:00 PM
To:	Tomcat Developers List
Subject:	Re: tomcat-committers mailing list

Martin Algesten wrote:


Just for our non-committers peace of mind, what is the purpose of this
list? What kind of "information" is it that we are to be denied or have
delayed?


Discussing for example possible security issues and resolve them
before making a public announce !




--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>




JTC will be tagged JK_1_2_1 within minutes ....

2002-11-26 Thread Henri Gomez
And just after being tagger, jk 1.2 will be moved to jk 1.2.2-dev (to 
follow the httpd way)


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 



JTC release 1.2.1 just tagged JK_1_2_1

2002-11-26 Thread Henri Gomez
Henri Gomez wrote:

And just after being tagger, jk 1.2 will be moved to mod_jk 1.2.2-dev (to 
follow the httpd way)

BTW, do you agree to change the version from jk-1.2.2-beta-1 to
mod_jk-1.2.2-dev, to follow the way Apache 1.3/2.0 numbering ?

I don't think will make ever beta-1, beta-2..

A+


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>




[Announce] JK 1.2.1 released

2002-11-26 Thread Henri Gomez
Hi to all,

mod_jk 1.2.1 has been released and is available at :

http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.1/

For now binaries are available for :

- Linux i386 (Apache 1.3 with/without SSL, Apache 2.0 with SSL)
- iSeries (Apache 2.0.39 for OS/400 V5R1/V5R2)

Other platforms ports should follow shortly.

Changes between JK 1.2.1 and JK 1.2.0 :

* Don't send initial chunk for chunked encoding,
  fix bugzilla report #14282
  [costin]

* Add perl scripts for analyzing mod_jk logs and
  generating graphs/reports
  [glenn]

* Make JK honor the CanonicalHost directive.
  [hgomez]

* Log cleanup
  [costin]

* Fix typos in jk xdocs/docs
  [hgomez]

* Add JkRequestLogFormat to Apache 2.0
  [hgomez]

* Final patches to make JK iSeries compliant
  [hgomez]


Regards


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: [ANNOUNCEMENT] JK2-2.0.2 released

2002-11-27 Thread Henri Gomez
Mladen Turk wrote:

Hi to all,

JK2 2.0.2 has been released and is available at :

http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk2/release/v
2.0.2/

For now binaries are available for WIN32 only:


linux binaries and rpms to be released tomorrow ;)



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: cvs commit: jakarta-tomcat-connectors/jk/native2/include jk_global.h

2002-11-27 Thread Henri Gomez
[EMAIL PROTECTED] wrote:

mturk   2002/11/27 09:12:05

  Modified:jk/native2/include jk_global.h
  Log:
  Change the version number to the 2.0.3 and mark as not nonreleased.
  The exposed version will be mod_jk2/2.0.3-beta-1.
  Perhaps we should change the beta to dev?


+1 to switch jk/jk2 to -dev, it's the Apache HTTPD numbering schema



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: [ANNOUNCEMENT] JK2-2.0.2 released

2002-11-28 Thread Henri Gomez
Henri Gomez wrote:

Mladen Turk wrote:


Hi to all,

JK2 2.0.2 has been released and is available at :

http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk2/release/v
2.0.2/

For now binaries are available for WIN32 only:



linux binaries and rpms to be released tomorrow ;)


While making the linux binaries, for Apache 2.0.43, I see that jkjni.so 
are not generated, only jkjni.a and jkjni.la ?

What's the problem ?



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>



Re: [ANNOUNCEMENT] JK2-2.0.2 released

2002-11-28 Thread Henri Gomez



Probably libtool. The one of the Apache 2.0.43 you are using.


What's the heck with libtool again ?





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: mod_jk-2.0.42.so

2002-11-28 Thread Henri Gomez
Pedro Igor Craveiro e Silva wrote:

I trying to configure the Apache + JServ, but a have a problem. When the apache is started it return a error message like this:

Cannot load /usr/local/www/apache/libexec/mod_jk-2.0.42.so into server: /usr/local/www/apache/libexec/mod_jk-2.0.42.so: Undefined symbol "ap_hook_post_config"
./apachectl startssl: httpd could not be started

My apache is a 1.3.27 and i using the AJP13 connector and tomcat 4.1.12.
Tanks,


mod_jk-2.0.42.so is for Apache 2.0.42 and later.

For Apache 1.3.27 use instead mod_jk-1.3-eapi.so (since you've got 
apache+mod_ssl)

Regards



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 



Re: [ANNOUNCEMENT] JK2-2.0.2 released

2002-11-28 Thread Henri Gomez
jean-frederic clere wrote:

Henri Gomez wrote:





Probably libtool. The one of the Apache 2.0.43 you are using.




What's the heck with libtool again ?



Look in the build/jk2/apache2/jkjni.la
Probably there is a jkjni.a instead jkjni.so there.


Yes jkjni.la and jkjni.a


May be you only have a libapr-0.a in your Apache 2.0.43.


No, I've got libapr.so

And I've got mod_jk2.so



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>




Re: mod_jk-2.0.42.so

2002-11-28 Thread Henri Gomez
Pedro Igor Craveiro e Silva wrote:

Thakns. ... but just one more, i don´t find this mod, do you have a clue ??



It's next to the other one !

http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.1/bin/linux/i386/mod_jk-1.3-eapi.so



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: [ANNOUNCEMENT] JK2-2.0.2 released

2002-11-28 Thread Henri Gomez
jean-frederic clere wrote:

Clere, Jean-Frederic wrote:


While building with Apache-1.3 I have the problem that it only builds 
with apxs:

cd jk/native2/server/apache13; gmake -f Makefile.apxs


The next problem is that this mod_jk2.so is not ok:
+++
bash-2.03$ bin/apachectl start
Syntax error on line 224 of 
/export/home2/apache20/apache26/conf/httpd.conf:
Cannot load /export/home2/apache20/apache26/libexec/mod_jk2.so into 
server: ld.so.1: /export/home2/apache20/apache26/bin/httpd: fatal: 
relocation error: file 
/export/home2/apache20/apache26/libexec/mod_jk2.so: symbol 
jk2_service_apache13_init: referenced symbol not found
bin/apachectl start: httpd could not be started
+++

apache13_init called in jk2 for Apache 2.0 ?



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: [ANNOUNCEMENT] JK2-2.0.2 released

2002-11-28 Thread Henri Gomez
Very weird.

Send me the complete output of make.


here it is :

httpd2/lib -lcrypt -lapr-0 -lpcre -lpcreposix 
../../../build/jk2/apache2/jk_jni_aprImpl.lo 
../../../build/jk2/apache2/jk_channel_apr_socket.lo 
../../../build/jk2/apache2/jk_channel.lo 
../../../build/jk2/apache2/jk_channel_jni.lo 
../../../build/jk2/apache2/jk_channel_socket.lo 
../../../build/jk2/apache2/jk_channel_un.lo 
../../../build/jk2/apache2/jk_config.lo 
../../../build/jk2/apache2/jk_config_file.lo 
../../../build/jk2/apache2/jk_endpoint.lo 
../../../build/jk2/apache2/jk_env.lo 
../../../build/jk2/apache2/jk_handler_logon.lo 
../../../build/jk2/apache2/jk_handler_response.lo 
../../../build/jk2/apache2/jk_logger_file.lo 
../../../build/jk2/apache2/jk_logger_win32.lo 
../../../build/jk2/apache2/jk_map.lo 
../../../build/jk2/apache2/jk_md5.lo 
../../../build/jk2/apache2/jk_msg_ajp.lo 
../../../build/jk2/apache2/jk_mutex.lo 
../../../build/jk2/apache2/jk_mutex_proc.lo 
../../../build/jk2/apache2/jk_mutex_thread.lo 
../../../build/jk2/apache2/jk_nwmain.lo 
../../../build/jk2/apache2/jk_objCache.lo 
../../../build/jk2/apache2/jk_pool_apr.lo 
../../../build/jk2/apache2/jk_pool.lo 
../../../build/jk2/apache2/jk_registry.lo 
../../../build/jk2/apache2/jk_requtil.lo 
../../../build/jk2/apache2/jk_shm.lo 
../../../build/jk2/apache2/jk_signal.lo 
../../../build/jk2/apache2/jk_uriEnv.lo 
../../../build/jk2/apache2/jk_uriMap.lo 
../../../build/jk2/apache2/jk_user.lo 
../../../build/jk2/apache2/jk_vm_default.lo 
../../../build/jk2/apache2/jk_worker_ajp13.lo 
../../../build/jk2/apache2/jk_workerEnv.lo 
../../../build/jk2/apache2/jk_worker_jni.lo 
../../../build/jk2/apache2/jk_worker_lb.lo 
../../../build/jk2/apache2/jk_worker_run.lo 
../../../build/jk2/apache2/jk_worker_status.lo
rm -fr ../../../build/jk2/apache2/.libs/jkjni.la 
../../../build/jk2/apache2/.libs/jkjni.* 
../../../build/jk2/apache2/.libs/jkjni.*

*** Warning: This library needs some functionality provided by -lapr-0.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have.

*** Warning: libtool could not satisfy all declared inter-library
*** dependencies of module jkjni.  Therefore, libtool will create
*** a static module, that should work as long as the dlopening
*** application is linked with the -dlopen flag.
ar cru ../../../build/jk2/apache2/.libs/jkjni.a 
../../../build/jk2/apache2/jk_jni_aprImpl.lo 
../../../build/jk2/apache2/jk_channel_apr_socket.lo 
../../../build/jk2/apache2/jk_channel.lo 
../../../build/jk2/apache2/jk_channel_jni.lo 
../../../build/jk2/apache2/jk_channel_socket.lo 
../../../build/jk2/apache2/jk_channel_un.lo 
../../../build/jk2/apache2/jk_config.lo 
../../../build/jk2/apache2/jk_config_file.lo 
../../../build/jk2/apache2/jk_endpoint.lo 
../../../build/jk2/apache2/jk_env.lo 
../../../build/jk2/apache2/jk_handler_logon.lo 
../../../build/jk2/apache2/jk_handler_response.lo 
../../../build/jk2/apache2/jk_logger_file.lo 
../../../build/jk2/apache2/jk_logger_win32.lo 
../../../build/jk2/apache2/jk_map.lo 
../../../build/jk2/apache2/jk_md5.lo 
../../../build/jk2/apache2/jk_msg_ajp.lo 
../../../build/jk2/apache2/jk_mutex.lo 
../../../build/jk2/apache2/jk_mutex_proc.lo 
../../../build/jk2/apache2/jk_mutex_thread.lo 
../../../build/jk2/apache2/jk_nwmain.lo 
../../../build/jk2/apache2/jk_objCache.lo 
../../../build/jk2/apache2/jk_pool_apr.lo 
../../../build/jk2/apache2/jk_pool.lo 
../../../build/jk2/apache2/jk_registry.lo 
../../../build/jk2/apache2/jk_requtil.lo 
../../../build/jk2/apache2/jk_shm.lo 
../../../build/jk2/apache2/jk_signal.lo 
../../../build/jk2/apache2/jk_uriEnv.lo 
../../../build/jk2/apache2/jk_uriMap.lo 
../../../build/jk2/apache2/jk_user.lo 
../../../build/jk2/apache2/jk_vm_default.lo 
../../../build/jk2/apache2/jk_worker_ajp13.lo 
../../../build/jk2/apache2/jk_workerEnv.lo 
../../../build/jk2/apache2/jk_worker_jni.lo 
../../../build/jk2/apache2/jk_worker_lb.lo 
../../../build/jk2/apache2/jk_worker_run.lo 
../../../build/jk2/apache2/jk_worker_status.lo
ranlib ../../../build/jk2/apache2/.libs/jkjni.a
creating ../../../build/jk2/apache2/jkjni.la
(cd ../../../build/jk2/apache2/.libs && rm -f jkjni.la && ln -s 
../jkjni.la jkjni.la)
/etc/httpd2/build/libtool  --mode=install  cp 
../../../build/jk2/apache2/jkjni.la `pwd`/../../../build/jk2/apache2
cp ../../../build/jk2/apache2/.libs/jkjni.lai 
/home/root/jakarta-tomcat-connectors-jk2-2.0.2-src/jk/native2/server/apache2/../../../build/jk2/apache2/jkjni.la
cp ../../../build/jk2/apache2/.libs/jkjni.a 
/home/root/jakarta-tomcat-connectors-jk2-2.0.2-src/jk/native2/server/apache2/../../../build/jk2/apache2/jkjni.a
ranlib 
/home/root/jakarta-tomcat-connectors-jk2-2.0.2-src/jk/native2/server/apache2/../../../build/jk2/apache2/jkjni.a
chmod 644 
/home/root/jakarta-tomcat-connectors-jk2-2.0.2-src/jk/native2/server/apache2/../../../build/jk2/apache2/jkjni.a
li

Re: [ANNOUNCEMENT] JK2-2.0.2 released

2002-11-28 Thread Henri Gomez
jean-frederic clere wrote:

Henri Gomez wrote:


Very weird.

Send me the complete output of make.




here it is :

httpd2/lib -lcrypt -lapr-0 -lpcre -lpcreposix 
../../../build/jk2/apache2/jk_jni_aprImpl.lo 
../../../build/jk2/apache2/jk_channel_apr_socket.lo 
../../../build/jk2/apache2/jk_channel.lo 
../../../build/jk2/apache2/jk_channel_jni.lo 
../../../build/jk2/apache2/jk_channel_socket.lo 
../../../build/jk2/apache2/jk_channel_un.lo 
../../../build/jk2/apache2/jk_config.lo 
../../../build/jk2/apache2/jk_config_file.lo 
../../../build/jk2/apache2/jk_endpoint.lo 
../../../build/jk2/apache2/jk_env.lo 
../../../build/jk2/apache2/jk_handler_logon.lo 
../../../build/jk2/apache2/jk_handler_response.lo 
../../../build/jk2/apache2/jk_logger_file.lo 
../../../build/jk2/apache2/jk_logger_win32.lo 
../../../build/jk2/apache2/jk_map.lo 
../../../build/jk2/apache2/jk_md5.lo 
../../../build/jk2/apache2/jk_msg_ajp.lo 
../../../build/jk2/apache2/jk_mutex.lo 
../../../build/jk2/apache2/jk_mutex_proc.lo 
../../../build/jk2/apache2/jk_mutex_thread.lo 
../../../build/jk2/apache2/jk_nwmain.lo 
../../../build/jk2/apache2/jk_objCache.lo 
../../../build/jk2/apache2/jk_pool_apr.lo 
../../../build/jk2/apache2/jk_pool.lo 
../../../build/jk2/apache2/jk_registry.lo 
../../../build/jk2/apache2/jk_requtil.lo 
../../../build/jk2/apache2/jk_shm.lo 
../../../build/jk2/apache2/jk_signal.lo 
../../../build/jk2/apache2/jk_uriEnv.lo 
../../../build/jk2/apache2/jk_uriMap.lo 
../../../build/jk2/apache2/jk_user.lo 
../../../build/jk2/apache2/jk_vm_default.lo 
../../../build/jk2/apache2/jk_worker_ajp13.lo 
../../../build/jk2/apache2/jk_workerEnv.lo 
../../../build/jk2/apache2/jk_worker_jni.lo 
../../../build/jk2/apache2/jk_worker_lb.lo 
../../../build/jk2/apache2/jk_worker_run.lo 
../../../build/jk2/apache2/jk_worker_status.lo
rm -fr ../../../build/jk2/apache2/.libs/jkjni.la 
../../../build/jk2/apache2/.libs/jkjni.* 
../../../build/jk2/apache2/.libs/jkjni.*

*** Warning: This library needs some functionality provided by -lapr-0.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have.

*** Warning: libtool could not satisfy all declared inter-library
*** dependencies of module jkjni.  Therefore, libtool will create
*** a static module, that should work as long as the dlopening
*** application is linked with the -dlopen flag.
ar cru ../../../build/jk2/apache2/.libs/jkjni.a 
../../../build/jk2/apache2/jk_jni_aprImpl.lo 
../../../build/jk2/apache2/jk_channel_apr_socket.lo 
../../../build/jk2/apache2/jk_channel.lo 
../../../build/jk2/apache2/jk_channel_jni.lo 
../../../build/jk2/apache2/jk_channel_socket.lo 
../../../build/jk2/apache2/jk_channel_un.lo 
../../../build/jk2/apache2/jk_config.lo 
../../../build/jk2/apache2/jk_config_file.lo 
../../../build/jk2/apache2/jk_endpoint.lo 
../../../build/jk2/apache2/jk_env.lo 
../../../build/jk2/apache2/jk_handler_logon.lo 
../../../build/jk2/apache2/jk_handler_response.lo 
../../../build/jk2/apache2/jk_logger_file.lo 
../../../build/jk2/apache2/jk_logger_win32.lo 
../../../build/jk2/apache2/jk_map.lo 
../../../build/jk2/apache2/jk_md5.lo 
../../../build/jk2/apache2/jk_msg_ajp.lo 
../../../build/jk2/apache2/jk_mutex.lo 
../../../build/jk2/apache2/jk_mutex_proc.lo 
../../../build/jk2/apache2/jk_mutex_thread.lo 
../../../build/jk2/apache2/jk_nwmain.lo 
../../../build/jk2/apache2/jk_objCache.lo 
../../../build/jk2/apache2/jk_pool_apr.lo 
../../../build/jk2/apache2/jk_pool.lo 
../../../build/jk2/apache2/jk_registry.lo 
../../../build/jk2/apache2/jk_requtil.lo 
../../../build/jk2/apache2/jk_shm.lo 
../../../build/jk2/apache2/jk_signal.lo 
../../../build/jk2/apache2/jk_uriEnv.lo 
../../../build/jk2/apache2/jk_uriMap.lo 
../../../build/jk2/apache2/jk_user.lo 
../../../build/jk2/apache2/jk_vm_default.lo 
../../../build/jk2/apache2/jk_worker_ajp13.lo 
../../../build/jk2/apache2/jk_workerEnv.lo 
../../../build/jk2/apache2/jk_worker_jni.lo 
../../../build/jk2/apache2/jk_worker_lb.lo 
../../../build/jk2/apache2/jk_worker_run.lo 
../../../build/jk2/apache2/jk_worker_status.lo
ranlib ../../../build/jk2/apache2/.libs/jkjni.a
creating ../../../build/jk2/apache2/jkjni.la
(cd ../../../build/jk2/apache2/.libs && rm -f jkjni.la && ln -s 
../jkjni.la jkjni.la)
/etc/httpd2/build/libtool  --mode=install  cp 
../../../build/jk2/apache2/jkjni.la `pwd`/../../../build/jk2/apache2
cp ../../../build/jk2/apache2/.libs/jkjni.lai 
/home/root/jakarta-tomcat-connectors-jk2-2.0.2-src/jk/native2/server/apache2/../../../build/jk2/apache2/jkjni.la 

cp ../../../build/jk2/apache2/.libs/jkjni.a 
/home/root/jakarta-tomcat-connectors-jk2-2.0.2-src/jk/native2/server/apache2/../../../build/jk2/apache2/jkjni.a 

ranlib 
/home/root/jakarta-tomcat-connectors-jk2-2.0.2-src/jk/native2/server/apache2/../../../build/jk2/apache2/jkjni.a 

chmod 644 
/home/root/jakarta-tomcat-connectors-

Re: [ANNOUNCEMENT] JK2-2.0.2 released

2002-11-28 Thread Henri Gomez
BTW: How did you build the mod_jk2.so for Apache-2.0?



mod_jk2.so didn't link against libapr, since apache2 allready provideit, 
but jkjni need it, that's why the build work for mod_jk2.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 



Re: mod_jk-2.0.42.so

2002-11-28 Thread Henri Gomez
Pedro Igor Craveiro e Silva wrote:

Thanks, Henri ... You came from the sky 



heuu, no from Lyon, France ;)




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: mod_jk-2.0.42.so

2002-11-28 Thread Henri Gomez
Pedro Igor Craveiro e Silva wrote:

Do you know what for is this libc.so.6 ?
When i run the httpd, he return that this shared lib could not be found.


Which release of Linux are you using ?




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: mod_jk-2.0.42.so

2002-11-28 Thread Henri Gomez
Pedro Igor Craveiro e Silva wrote:

I´m not using Linux, but FreeBSD.


Hum, that's why !!!

BTW, the is no Apache 1.3 binary for FreeBSD,
I only built one for Apache 2.0 ;(



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: mod_jk-2.0.42.so

2002-11-29 Thread Henri Gomez
Pier Fumagalli wrote:

On 28/11/02 7:37 pm, in article 000701c2970d$2d408f90$[EMAIL PROTECTED],
"Pedro Igor Craveiro e Silva" <[EMAIL PROTECTED]> wrote:



Ok.
But, with that first module(mod_jk2.(etc)) the i was using i can put the
apache e tomcat together?



FreeBSD contains a Linux "emulator", but AFAICR, it ships currently with
GLIBC-5 ... You'd better off recompiling the module (Apache part) native for
FreeBSD and the JNI lib for Linux GLIBC-5...


+1

Prefer a native port or install Apache 2.0.43 for FreeBSD...





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: Double Version

2002-12-02 Thread Henri Gomez
Laxmikanth M.S. wrote:

Hi ,


A question for tomcat-user list please.


I have installed two versions of Tomcat and apache running together on the
same Machine
Apache1.3.27 - Tomcat3.3.1
Apache1.3.27 - Tomcat4.1.12


Make Apaches and Tomcats listens on differents ports:

Apache1.3.27 (80) - Tomcat3.3.1 (8080, 8007, 8009)
Apache1.3.27 (8092) - Tomcat4.1.12 (8180, 8109)


is it possible to run the servers in the same macine.
I am not able to start apache servers. Is there any way to resolve this.
thanks
Regards
Laxmikanth M S 
Off*  : 91-80-6610330 extn 1256
Res* : 91-80-5267150
http://www.sonata-software.com


Coming together is the beginning, staying together is progress and working
together is Success


What lies behind us and what lies before us are tiny matters compared to
what lies within us  - Emerson


*
Disclaimer: The information in this e-mail and any attachments is
confidential / privileged. It is intended solely for the addressee or
addressees. If you are not the addressee indicated in this message, you may
not copy or deliver this message to anyone. In such case, you should destroy
this message and kindly notify the sender by reply email. Please advise
immediately if you or your employer does not consent to Internet email for
messages of this kind.
*

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 







--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Bad version used for jk 1.2.1

2002-12-03 Thread Henri Gomez
Bad windows binaries present at :

http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.1/bin/win32/

They report as mod_jk-1.2.2-beta-1 instead of jk 1.2.1.

Could someone get the source code and make a new build ?

Thanks


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: Apache Tomcat 4.1.16 AJP not working

2002-12-03 Thread Henri Gomez
M wrote:

Looking at the netstat on the machine I can see tomcat is bound to the
port 8009 and can connect to it with telnet, apache works if I go back
to tomcat 4.1.14.


From the apache logs:


[Tue Dec 03 16:04:22 2002]  [jk_connect.c (143)]: jk_open_socket,
connect() failed errno = 111
[Tue Dec 03 16:04:22 2002]  [jk_ajp13_worker.c (196)]: In
jk_endpoint_t::connect_to_tomcat, failed errno = 111
[Tue Dec 03 16:04:22 2002]  [jk_ajp13_worker.c (635)]: Error connecting
to the Tomcat process.
[Tue Dec 03 16:04:22 2002]  [jk_ajp13_worker.c (848)]: In
jk_endpoint_t::service, send_request failed in send loop 0

As we're using apache 1.3 and can't use warp it's fairly critical to
us...
should I raise a bug report?


Which release of mod_jk ?

You should try the 1.2.1 release



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: [5.0] Cluster features

2002-12-03 Thread Henri Gomez
Remy Maucherat wrote:

Hi,

I think the clustering features in Tomcat 5 should get an overhaul.
Despite some licensing dicrepancies, I plan to use JavaGroups for the
task (LGPL license), as well as some code which was donated a while ago
by Filip Hanik. Based on what is already done, the amount of work that 
will have to be done to have quality clustering features seems small.

Most of the current clustering API will be removed in the process, since
it doesn't seem to be maintained anymore, and didn't evolve past
experimental stage (if I am wrong on that, let me know).

I also plan to bundle JavaGroups with Tomcat 5, as it only adds a 1MB
standalone JAR. Configuring Tomcat for clustering will be quite easy
once all the code is in place.

I don't know if that plan is acceptable for everyone. Originally,
I -1ed the code submission because of licensing and absence of
integration with the existing Cluster API. The licensing issue is still 
there, but since the Cluster API now seems sort of dead, another 
solution has to be found (IMO, of course there's JK available).

Comments ?

I could be a full +1, if we could convince them to make JavaGroups 
BSD/Apache licence.

Or use something related with BSD license (see mod_backend)

Regards




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 



Re: [5.0] Cluster features

2002-12-04 Thread Henri Gomez
Filip Hanik wrote:

we have a project on sourceforge to continue development of this.
but we would love to integrate this into Tomcat where it really belongs.
http://sourceforge.net/projects/tomcat-jg


It seems JavaGroup could be a great candidate as jakarta project,
you even got the right look :)

http://www.javagroups.com/javagroupsnew/docs/index.html

What about changing licence to BSD/Apache and ask for being
a jakarta project ?

You'll have my full +1 (and of many tomcat developpers).

Gain :

- You'll could put your tomcat jg works back in TC 4.x

- You'll provide a great API to jakarta where many projects
  could have the need of.

And of course you'll find many new friends here in ASF ...






--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: [VOTE] Tomcat modules

2002-12-09 Thread Henri Gomez
Remy Maucherat wrote:

Hi,

I plan to reorganize the jakarta-tomcat-catalina repository as follows:
- catalina folder: Catalina core; this depends on the servlet API
- modules folders: Optional functionality and modules (one example is 
clustering), but which depends on the Catalina API; this does not 
directly depend on the servlet API

Alternately, using another repository (j-t-modules) is possible, but 
just using a folder looks simpler, as there is an API dependency.

I propose putting independent modules in j-t-connectors (like eventually 
some of the naming features).


+1 [ ]
-1 [ ]


+0

I'm pretty busy these days so I can't help even if this
and the clustering are of very interest for me.

Regards



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: [VOTE] minimal JSR 154 only distribution

2002-12-09 Thread Henri Gomez
Jon Scott Stevens wrote:

on 2002/12/7 9:37 AM, "Glenn Nielsen" <[EMAIL PROTECTED]> wrote:



I will consider voting +1 if any of the other tomcat devs who want this
will volunteer to be the release manager for the servlet only distribution.

I would find this handy when using Tomcat as a SOAP server where JSP is
not needed.

Glenn


Well this thread make some noise.


I will volunteer to be the release manager.


How will you synchronise with main branch ?

Will you wait TC 5 release to make the SMALL TC5 distro or
will you follow another cycle of release ?





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: [VOTE] minimal JSR 154 only distribution

2002-12-09 Thread Henri Gomez
Pier Fumagalli wrote:

On 8/12/02 0:43 "Jon Scott Stevens" <[EMAIL PROTECTED]> wrote:



on 2002/12/7 4:25 PM, "Pier Fumagalli" <[EMAIL PROTECTED]> wrote:



Jon, I'm very sorry mate, you're 4 months too late :-( I lost my fight about
this very same topic back then...


Maybe to late for your opinion, but honestly, I haven't been that impressed
with Jetty.



In my case it speeds up my stuff around 3/4 times faster. And the footprint
is considerably slower... Depends on the app...


I make benchs between TC 4.1.16 and latest jetty, and TC 4.1 was about 
30% faster on servlet (didn't test JSP).

I saw very little if any speed increase with Jetty and Scarab and I actually
consider Jetty's distribution to be packed with more crud than
Tomcat's...but maybe I'm just biased by Tomcat.



At this point, I don't think that with JSR 154 and JSR 152 being separate,
there is much that anyone here can say negative about distributing JSR 154
only engine. Clearly there is a demand. Clearly it is a good thing to have
options.


What think JCP about a JSR 154 only engine ?



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




adding content-type for Apache 2.0 jk/jk2

2002-12-09 Thread Henri Gomez
Hi,

I'm playing currently with mod_jk + mod_deflate on Apache 2.0,
and it seems it will be needed to set the content-type in response
in Apache 2.0 to allow mod_deflate to compress only text/html, text/xml
contents.

It seems in that case will need to parse the tomcat response
to set content-type accordingly with ap_set_content_type.

What do you think about ?


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: [VOTE] minimal JSR 154 only distribution

2002-12-09 Thread Henri Gomez
Ignacio J. Ortega wrote:

Jon,



Create a separate minimal JSR 154 only distribution of Tomcat 4.x:




+0, i could be +1 but i'm out of time to offer any help in tomcat as a
whole, and of course for this particular proposal, but i dont see
anything wrong in it, more i do see it as another step, in the GTU Path
( GTU stand for "Great Tomcat Unification" :).. 

Nota that adopting modules for Tomcat could be a way to
satisfy everybody needs.

In such case I'm +1 to have a minimal Tomcat which will
load modules to have JSP, JMX, admin supports.

If anything could be set in server.xml, it will help
have an uniq distribution, that everybody will be able
to tune for its own use.




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: [VOTE] Minimal tomcat ( JSR154 + JSR152 )

2002-12-09 Thread Henri Gomez
Costin Manolache wrote:

Since things may get confusing around here, I would like to 
have an official vote on my prior proposal.

This is the list of included features:

Libs:
- JMX
- JAAS
- JNDI
- digester ( and beanutils, collections it needs ). 
- modeler
- ant ( used for startup and automation of some tasks )
- commons-logging
When/if the JNDI-based abstraction of config files is ready we'll not
need digester - but most likely it'll still be required by
modeler, and also by jasper, so I don't think we can remove it.

Tomcat:
- subset of catalina ( non-deprecated interfaces and base impl that is 
required for tomcat to work ).
- coyote
- tomcat-util
- http11/jk2
- all valves/etc that are required for tomcat to operate.
- naming
- jasper ( at least jasper runtime - but probably the whole thing ).

Votes:
[ ] +1 I like the idea, I might help
[ ] -1 I don't like the idea, I won't help.

+0,5 :

I like the idea, but have little time to help these days.



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: [VOTE] minimal JSR 154 only distribution

2002-12-09 Thread Henri Gomez
Remy Maucherat wrote:

Costin Manolache wrote:


Remy Maucherat wrote:




If the vote actually passes, I'd like to have only one minimal Tomcat
distribution, which would mean no admin and no Jasper (with separate
optional Jasper binaries available). JMX can be used directly (using a
MX4J connector + MC4J, assuming MC4J updates to MX4J 1.1.1 as we did) to
administer the server, without the need to use the admin webapp.




Now - this is not nice !

I don't know why my proposal for a minimal tomcat that includes jsr152 
and
jsr154 shouldn't be allowed.
Ok, I'll make a VOTE and try to gather the votes - hopefully I'll
get at least 3 +1 votes ( and you'll at least -0 it :-).


I'd really like to avoid the proliferation of too many distributions. 
The light distribution confused a lot of users who didn't know what they 
needed, from what I've seen (from what I've read on tc-user).

To restate it: if we do a minimal version and it is voted to be Jasper 
less, then I think we shouldn't have a third minimal-but-with-Jasper 
distribution. Rather, I'd have a separate binary holding the Jasper 
JARs. That's just my preference anyway.

BTW, in such vote, it should be Yes or No. If you don't care, then you 
shouldn't vote.

What about using a minimal tomcat core with plugged modules to give
access to jsp/jmx ?

Will make both Costin, and Jon happy and let us have only one
distribution with clear indication in server.xml on how to
activate/desactive such module.





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: adding content-type for Apache 2.0 jk/jk2

2002-12-09 Thread Henri Gomez
Henri Gomez wrote:

Hi,

I'm playing currently with mod_jk + mod_deflate on Apache 2.0,
and it seems it will be needed to set the content-type in response
in Apache 2.0 to allow mod_deflate to compress only text/html, text/xml
contents.

It seems in that case will need to parse the tomcat response
to set content-type accordingly with ap_set_content_type.

What do you think about ?


Ok, I didn't wait and sus updated jk/jk2 and also mod_webapp
to set the content-type correctly for Apache 2.0.

Regards



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>




Re: [VOTE] minimal JSR 154 only distribution

2002-12-10 Thread Henri Gomez
Jon Scott Stevens wrote:

on 2002/12/9 7:27 AM, "Remy Maucherat" <[EMAIL PROTECTED]> wrote:



I'd really like to avoid the proliferation of too many distributions.



I don't agree with that. There is nothing wrong with giving users choices.


There is many things something wrong with many distributions :

- Users may be puzzled by seeing too many tomcat distributions.

- Who will be the release managers for the 'alternative distributions',
  may be Jon is candidate ?


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: [VOTE] minimal JSR 154 only distribution

2002-12-10 Thread Henri Gomez
Jon Scott Stevens wrote:

on 2002/12/9 7:32 AM, "Henri Gomez" <[EMAIL PROTECTED]> wrote:



What about using a minimal tomcat core with plugged modules to give
access to jsp/jmx ?

Will make both Costin, and Jon happy and let us have only one
distribution with clear indication in server.xml on how to
activate/desactive such module.



That does not make me happy. You are missing my point. Read the subject line
of this message.


I read YOUR SUBJECT LINE, and that's why I feel that a common
distribution with modules could be the solution.

The idea being to provide a minimal tomcat binary and
many external modules which will be linked at runtime if
present, Apache 2.0 does it that way, why could we do the
same.

All we need is a more modular approach of TC 5, which should
be able to load modules (JMX/JASPER) if available in classpath.

If you take a look at how decent packaging tools like rpm/debian
works, they are able to install a PRIMARY PACKAGE and OPTIONAL
PACKAGES. For your purpose, scarab for example, you could only
stay with the bare minimum TC 5, without installing the rest
of TC 5.

What about ?


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>




Re: [VOTE] minimal JSR 154 only distribution

2002-12-10 Thread Henri Gomez
Pier Fumagalli wrote:

On 9/12/02 17:14 "Jeanfrancois Arcand" <[EMAIL PROTECTED]> wrote:



Youy don't need to learn JSP/Admin Tool if you don't use it. The actual
Tomcat installation doesn't require you to learn the Admin Tool or JSP



As I said 6 or so months ago... That "thing" is a security hole as big as
the Empire State Building... As most of the stuff that make up "tomcat"...
We have some bugs in JSR-154, few in Jasper, few in JSSI, few in CGI... All
together it makes a load of em...


I didn't understand the problem with the admin/manager tools, since
they aren't mandatory and very easy to desactivate.


If someone can come up with a Servlet-only distribution, at least I won't
get holes from all the other (totally useless) components...


JSP ?


Pier (a _user_ now)


And that's sad.



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Minimal or Modular it's up to you

2002-12-10 Thread Henri Gomez
There was many noise these days about making another
release of tomcat (the minimal one covering only JSR154),
and another proposal to make a modular Tomcat.

It may be because my mother language is french, but I
still didn't understand why Tomcat commiters didn't
find an arrangement on these 2 proposals which GOES
in the same direction.

What Jon and Pier want is a minimal distribution of
Tomcat 5.

What Costin proposed is to make Tomcat 5 more modular,
which is very similar to what make Apache HTTP server
so successfull.

Why didn't merge the both proposal ?

- Make a Tomcat distribution which is composed of :

  - a minimal tomcat core
  - extension modules.

People will be free to install the core, and the modules
they want to use (JMX/JASPER/JNDI/JK2).

Java is not so bad in introspection and class discovery
and should be able to detect what is present and what
could be activated.

To mimic the HTTPD way, the server.xml could have entries
likes these :




  
debug="0"/>
  
debug="0"/>








   port="8009" minProcessors="5" maxProcessors="75"
   enableLookups="true" redirectPort="8443"
   acceptCount="10" debug="0" connectionTimeout="2"
   useURIValidationHack="false"

protocolHandlerClassName="org.apache.jk.server.JkCoyoteHandler"/>





The goal will be :

- make happy people who need a minimal distribution, for example
  those who want to embed it on low memory device.

- make happy people who want to get the full artillery to play
  and experiment with.

- and in fine attract 'modules' writers, à la HTTPD way, developpers
  which make Apache 1.x/2.x servers so widely used today.


And of course, restore the consensus which was present till the TC 5.0
project was initiated by the commiters who previously spent many times
developping each one THEIR OWN vision of servlet container (3.3/4.0).

But we're in a real world and since commiters are after all humans, I
politely recommand to people who do NOT REALLY WANT TO BE CONSTRUCTIVE 
and may restart a new Tomcat War, to try to convince others teams
making others servlet implementation.




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 



Re: Minimal or Modular it's up to you

2002-12-10 Thread Henri Gomez
Jon Scott Stevens wrote:

on 2002/12/10 1:19 AM, "Henri Gomez" <[EMAIL PROTECTED]> wrote:



What Jon and Pier want is a minimal distribution of
Tomcat 5.



No. What I want is a distribution of a JSR 154 container with nothing more
than the RI of JSR 154. Period.


Ok, so just take the tomcat core and don't install/activate
the jasper module.



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>




Re: [VOTE] Minimal tomcat ( JSR154 + JSR152 )

2002-12-10 Thread Henri Gomez
Pier Fumagalli wrote:

On 10/12/02 8:40 am, in article [EMAIL PROTECTED], "Remy
Maucherat" <[EMAIL PROTECTED]> wrote:



Like the httpd, I'd prefer having a full distribution of all safe (yes,
Jasper is safe) and generally useful modules. Experienced users can
tweak the configuration to their liking, and it is easy to do, but the
beginners get an easy to run environment which does what they need (and
obviously a lot more, since you'd want the distribution to fill the
needs of 95% of users).



There is one big huge difference... Modules are DSOs, if you don't enable
them in your httpd.conf, they don't get loaded, they don't get used

Disabling all of them can be done by "sed 's/^LoadModule/#LoadModule/g'".

If you get a binary distribution... (which, btw, doesn't enable most of
them, it just _ships_ them in the same bundle...)

If you don't get a binary distribution, when I build, I have a lot of tiny
--enable and --disable flags... I can _choose_ what to build, what to
install, what goes on my machine... This doesn't happen with Tomcat and it
SUCKS ASS. :-)


It's exactly what SHOULD BE DONE in a modular approach of TC 5.

A small core with essential functionalities, and a bunch of modules,
which will live in modules dir or activated if module-xxx.xml found
in conf directory of tomcat.


Don't compare yourself to HTTPD, learn from them, that's the only thing you
can do... :-) (suggestion from someone who has been around long enough).


I learn HTTPD everyday, and yesterday I even correct
mod_webapp for Apache 2.0 !


New signature! :-)

Pier


nananere


--
[...] mod_webapp,  which was *the* main reason for  many people not to adopt
Tomcat 4.x - Remy MaucheratWorks for me - Pier Fumagalli


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 







--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: [VOTE] minimal JSR 154 only distribution

2002-12-10 Thread Henri Gomez
Jon Scott Stevens wrote:

on 2002/12/10 12:53 AM, "Henri Gomez" <[EMAIL PROTECTED]> wrote:



The idea being to provide a minimal tomcat binary and
many external modules which will be linked at runtime if
present, Apache 2.0 does it that way, why could we do the
same.



You are repeating my ideas that I have already said on the list.


Yes but add the ability to activate/include modules, which is
the Costin idea ;)



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>




Re: [VOTE] minimal JSR 154 only distribution

2002-12-10 Thread Henri Gomez
Jon Scott Stevens wrote:

on 2002/12/10 12:49 AM, "Henri Gomez" <[EMAIL PROTECTED]> wrote:



- Who will be the release managers for the 'alternative distributions',
may be Jon is candidate ?



I already volunteered to manage the distribution that I propose.

I have been doing distributions of servlet containers since you guys were in
diapers.


Jon, you're a little younger than me so, 'du respect'.

BTW, we're not discussing here what has be done in the past
but what should be done in the future.







--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>




Re: [VOTE] New committer: Filip Hanik

2002-12-10 Thread Henri Gomez
Remy Maucherat wrote:

I'd like to nominate Filip Hanik  as a committer on 
the Tomcat project. Filip has written the clustering code that was 
committed recently in the Tomcat 5 CVS, and is willing to maintain it, 
as well as continuing to improve it (including supporting large 
clusters). Filip is one of the authors of JavaGroups, the Java based 
clustering framework used in the new Tomcat clustering code.

+1

and +100 to have javagroups as a Jakarta project.



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: [PATCH] mod_jk - chroot and user issues

2002-12-11 Thread Henri Gomez
Kurt Miller wrote:

I recently created a port of mod_jk-1.2.1 for OpenBSD and needed to make
some minor patches to mod_jk. OpenBSD 3.2 has Apache 1.3.26 configured as
ServerType standalone, to chroot to /var/www and run as user www by default.
This combination requires a few minor patches so that mod_jk will continue
to work after an Apache restart.


I'm fine with the makefile updates but there is a problem with change in
apache-1.3/mod_jk.c since there is no ap_server_strip_chroot call
available on my Linux box.

Is it an OpenBSD specific call ?

If so we'll have to add some #ifdef OPEN_BSD and I'd like to
have others jk commiters opinion. (I allready put too much
#ifdef AS400 ;)

I'll be to use a #ifdef CHROOTED_APACHE :

--- apache-1.3/mod_jk.c.orig	Tue Nov 26 12:26:25 2002
+++ apache-1.3/mod_jk.c	Mon Dec  9 01:59:18 2002
...

 /* we need an absolut path */
 conf->worker_file = ap_server_root_relative(cmd->pool,worker_file);
#ifdef CHROOTED_APACHE
 ap_server_strip_chroot(conf->worker_file,0);
#endif

 if (conf->worker_file == worker_file)
 conf->worker_file = ap_pstrdup(cmd->pool,worker_file);




 /* we need an absolut path */
 conf->log_file = ap_server_root_relative(cmd->pool,log_file);
#ifdef CHROOTED_APACHE
 ap_server_strip_chroot(conf->log_file,0);
#endif

 if ( conf->log_file == log_file)
 conf->log_file = ap_pstrdup(cmd->pool,log_file);



@@ -1742,7 +1746,7 @@ static void jk_init(server_rec *s, ap_po
 /* Open up log file */
 if(conf->log_file && conf->log_level >= 0) {
 if(!jk_open_file_logger(&(conf->log), conf->log_file, 
conf->log_level)) {
#ifdef CHROOTED_APACHE
conf->log = main_log;
#else
 conf->log = NULL;
#endif
 } else {
 main_log = conf->log;
 }



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 



Re: cvs commit: jakarta-tomcat-connectors/jk/native/apache-1.3 mod_jk.c

2002-12-11 Thread Henri Gomez
[EMAIL PROTECTED] wrote:

hgomez  2002/12/11 02:40:38

  Modified:jk/native/apache-1.3 mod_jk.c
  Log:
  Allow log file use in chrooted (for now only OpenBSD) environement.

  

  You'll have to define CHROOTED_APACHE (or later will use the define

  added by OpenBSD if any)

  provided by Kurt Miller.
  

if OpenBSD (and other chrooted Apache) have a specific define, I'll
use it instead of CHROOTED_APACHE.

Regards



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: [VOTE] minimal JSR 154 only distribution

2002-12-12 Thread Henri Gomez
Costin Manolache wrote:

Bill Barker wrote:



Urm, err, the users that can't read may include you ;-). Jon withdrew the
vote above.  This means that this is officially 'not getting anywhere', at
least until Jon re-submits his re-worked proposal.



The fact that Jon withdrew the vote doesn't change any of the arguments
and opinions that were expressed about profiles and minimal.

IMO we are very close to consensus on "profiles", and I think we can
rich a consensus on an "embeded".

I think we should just change the subject line - and have another vote
to make sure we're all on the same page.


Agreed.




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: [PATCH] mod_jk - chroot and user issues

2002-12-13 Thread Henri Gomez
FWIW, I like the feature based define. If other OS's or Apache incorporate
OpenBSD's chroot option, then it wouldn't need to be changed. On the other
hand, if the consensus is not to commit the patch into mod_jk to keep the
cruft down, the OpenBSD port can apply the patch (assuming my port is
committed).


Ok, it's in jk CVS and you'll just have to add -DCHROOTED_APACHE
to check it.

Thanks to give some feedback.

Regards


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: [PATCH] mod_jk - chroot and user issues

2002-12-16 Thread Henri Gomez
Kurt Miller wrote:

Ok, it's in jk CVS and you'll just have to add -DCHROOTED_APACHE
to check it.

Thanks to give some feedback.




Thank you for commiting the patches. :-)

I tested them and noted one problem with apache-1.3/Makefile.in. It includes
../common/list.mk which requires the JK=../common line to be there.


Fixed thanks



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




mod_jk to be tagged tomorrow

2002-12-16 Thread Henri Gomez
If nobody object, I'll tag JK 1.2.2 later todaty since it fix
a major problem with content-type and it works now with mod_deflate
in Apache 2.0.

Regards


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: mod_jk to be tagged tomorrow

2002-12-16 Thread Henri Gomez
Glenn Nielsen wrote:

Henri Gomez wrote:


If nobody object, I'll tag JK 1.2.2 later todaty since it fix
a major problem with content-type and it works now with mod_deflate
in Apache 2.0.




I noticed that there is no release notes or changes file either in CVS 
or in
the distributions.  Could this please be added. It would sure make things
easier for those upgrading to quickly identify what changes have been made
or what bugs have been fixed.

There is a CHANGES.txt :

JAKARTA TOMCAT CONNECTORS (JK) CHANGELOG:			-*-text-*-
Last modified at [$Date: 2002/12/09 13:28:55 $]

Changes with JK 1.2.2:
* jk set correctly the content-type in Apache 2.0,
  making it ready to works with mod_deflate and AddOutputFilterByType
  [hgomez]
* jk will check result of get_endpoint and handle a failure.
  This call can fail if the allocation for the endpoint fails 
because of low memory conditions
  causing a dereference of NULL when we try and access the endpoint
  [mmanders]

Changes with JK 1.2.1:
* Don't send initial chunk for chunked encoding, fix #14282
  [costin]
* Add perl scripts for analyzing mod_jk logs and generating 
graphs/reports
  [glenn]
* Make JK honor the CanonicalHost directive.
  [hgomez]
* Log cleanup
  [costin]
* Fix typos in jk xdocs/docs
  [hgomez]
* Add JkRequestLogFormat to Apache 2.0
  [hgomez]
* Final patches to make JK iSeries compliant
  [hgomez]




--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>



Re: [PROPOSAL][TOMCAT5] plugins directory

2002-12-16 Thread Henri Gomez
Costin Manolache wrote:

There are several things we discussed last week, and few seem to
have enough consensus. 
This is an initial proposal - I expect it to change quite a bit. I think 
it's very important and will affect almost everyone - so please send at
least a numeric vote, and if possible comments or sugestions. If we
do agree - we'll need to also do the work, so please indicate if
you are willing to write at least some of the code :-)

We seem to agree on having a more modular tomcat, where different
components can be added ( by a script, manually, etc ) or removed
easily. The mechanisms of adding/removing components is a separate
issue that can be decided in a separate thread.

My initial proposal is:

1. Add a new plugins/ directory. All tomcat components will eventually
be migrated from server/lib and common/lib into one of the plugins
subdirectories. ( it can be called modules/ or something else ).

2. The "profile" will consist of a list of plugins that are enabled.
This can be configured using an XML file or using an API ( details 
of this are a separate item ). Tomcat will _not_ load all plugins 
automatically ( like in webapps/ or tomcat33 modules ), you'll have
to explicitely add each of them.

3. The format of a plugin. We should support at least .war ( tomcat
already have all the code ). I don't see a need for a format that
is very different, but we (may) need to add an additional XML file.
We should also be able to support a .jar format ( maybe with an
additional .xml descriptor in META-INF ) as well as .xml descriptors
in the plugin directory.

4. Each plugin will define one or several MBeans. Regular JMX API
will be used to add/remove plugins, and the normal JMX notifications
will be used to detect and plug the plugins into the server. It should
be possible for an application embeding tomcat to add MBeans from
any other locations.

5. The XML should be similar with the MLET format ( with some extensions if
we need to ). I don't see any need for something more complicated or
different.

6. Each classloader in tomcat will be ( or have ) a MBean. Different
plugins can define new classloaders ( by using an mbean declaration ) 
or add jars to existing classloaders ( in particular the server, 
common and individual webapp loaders ).

7. Tomcat startup will be modified to start with only JMX and whatever
minimal code we need to load plugins. The common and server loaders will be 
defined by the plugins. All classloader configuration will be consolidated. 
The ant startup will also be changed to use the same xml format ( 
8. Tomcat should work with no config file - using only JMX API calls
to load it and configure a set of plugins ( profile ), using whatever
class loader and layout the embeding application ( ant, etc ) wants.  

A big +1 (even if I may have very little time to help the next months)




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




JK 1.2.2

2002-12-17 Thread Henri Gomez
jtc cvs tagged JK_1_2_2



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




[ANNOUNCE] JK 1.2.2 released

2002-12-17 Thread Henri Gomez
JK 1.2.2 maintenance release is available at :

http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.2/

Changes with JK 1.2.2:

* tomcat_trend.pl updated script to support changed logging of
  aborted requests

* jk set correctly the content-type in Apache 2.0,
  making it ready to works with mod_deflate and
  AddOutputFilterByType

* jk will check result of get_endpoint and handle a failure.
  This call can fail if the allocation for the endpoint fails
  because of low memory conditions
  causing a dereference of NULL when we try and access the endpoint


Sources, Linux (flat/rpms) and iSeries binaries are already available,
Windows, Solaris, MacOS X binaries will be released soon.

Regards.

iSeries Note:

Previous JK binaries for iSeries (AS/400) were built without
TERASPACE support nor multi-threading support code and should be
considered incorrect.

Production sites should upgrade to this version.

Binaries Providers:

We're looking for binaries contributors for AIX and FreeBSD
(Apache 1.3 (w/wo SSL) and Apache 2.0.42 or higher).





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: [VOTE] New committer: Filip Hanik

2002-12-17 Thread Henri Gomez
Remy Maucherat wrote:

Glenn Nielsen wrote:


+1 Welcome aboard Filip



A little bit late, as Filip already got his account ;-)
Welcome on board Filip :)


Did there is any chance to have one day javagroups as an
jakarta project covered by an ASF license ?



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




gzip-encoding in TC 4.1.x/5.x

2002-12-17 Thread Henri Gomez
I spent some times playing with http compression,
using Apache 2.0 mod_deflate together with mod_jk,
and it works great (at least with jk 1.2.2).

I wonder now if someone, may be Remy, has plan to
add it in Catalina 1.x/2.x (or Coyote) to make it
available for both HTTP 1.1 and JK2 ?

For those who want to experiment JK+DEFLATE
here is was to add in httpd.conf :

---

...

LoadModule jk_module /modules/mod_jk.so
LoadModule deflate_module /modules/mod_deflate.so

...

#
# MOD_DEFLATE
#
# Netscape 4.x has some problems...
BrowserMatch ^Mozilla/4 gzip-only-text/html
# Netscape 4.06-4.08 have some more problems
BrowserMatch ^Mozilla/4\.0[678] no-gzip
# MSIE masquerades as Netscape, but it is fine
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
# Don't compress images
SetEnvIfNoCase Request_URI \.(gif|jpe?g|png)$ no-gzip dont-vary
# Make sure proxies don't deliver the wrong content
Header append Vary User-Agent env=!dont-vary



#
# Logging
#
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" 
combined 

LogFormat "%h %l %u %t \"%r\" %>s %b" common 

LogFormat "%{Referer}i -> %U" referer 

LogFormat "%{User-agent}i" agent 

DeflateFilterNote ratio
LogFormat '"%r" %b (%{ratio}n) "%{User-agent}i"' deflate




ServerName myhost.org
ServerAdmin [EMAIL PROTECTED]

#
# DEFLATE
#
AddOutputFilterByType DEFLATE text/html text/plain text/xml
DeflateFilterNote ratio
LogFormat '"%r" %b (%{ratio}n) "%{User-agent}i"' deflate



JkMount /* ajp13

...





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 



Re: gzip-encoding in TC 4.1.x/5.x

2002-12-17 Thread Henri Gomez
Remy Maucherat wrote:

Henri Gomez wrote:


I spent some times playing with http compression,
using Apache 2.0 mod_deflate together with mod_jk,
and it works great (at least with jk 1.2.2).

I wonder now if someone, may be Remy, has plan to
add it in Catalina 1.x/2.x (or Coyote) to make it
available for both HTTP 1.1 and JK2 ?



I was planning to add the feature as filters in Coyote HTTP/1.1, but 
never did, because I wasn't able to find efficient compression code. I 
suppose something could be put together using the JDK compression IS and 
OS in the meantime.

GZIPOutputstream is quit fast today.


For JK 2, I think it's fair to say that you should rely on the native 
webserver capabilities (that's the whole point, I think). Great that you 
added the support (I thought it had been there from the start, actually).

Hum, the idea to put compression on the Java side (HTTP 1.1/JK2) is to
reduce the response time and network bandwidth when webserver and tomcat
are linked TCP/IP (ie ajp13 + network).

I make some bench on large output streams and even if mod_deflate help
by sending to browser smaller responses, it still has to handle the
big response caming from tomcat.

That's why it could be a real gain to have gzip compression also on
the tomcat side, I think you'll see real gain with recent browser as
soon as response is more than 10k.

I hope someone could works on it at the coyote level to make
it available for both HTTP 1.1 and JK2 upper layers.

There is some things to care off, ie activation of compression
on certains mimes contents (ie: text/html, text/plain) and
when size is greater than xxx bytes.

If someone has ideas and may be a skeleton for coyote, I may help
him on this area.

Regards




--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>




Re: gzip-encoding in TC 4.1.x/5.x

2002-12-17 Thread Henri Gomez
For JK 2, I think it's fair to say that you should rely on the native 
webserver capabilities (that's the whole point, I think). Great that you 
added the support (I thought it had been there from the start, actually).

I didn't added support really, just corrected the way we set the
content-type in Apache 2.0 using the correct API ;)



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: gzip-encoding in TC 4.1.x/5.x

2002-12-17 Thread Henri Gomez
I was planning to add the feature as filters in Coyote HTTP/1.1, but 
never did, because I wasn't able to find efficient compression code. 
I suppose something could be put together using the JDK compression 
IS and OS in the meantime.



GZIPOutputstream is quit fast today.



I think I'll disagree whenever I'll try it.


C'est le jeu ;)


Ideally, I'd like a ByteChunk compress(ByteChunk) with nice recycle 
methods so that no object even gets allocated.

Right, but I'm currently playing with stuff which read/write
large files, and reading/writing with GZIPstream make the
program 4* faster !

I hope someone could works on it at the coyote level to make
it available for both HTTP 1.1 and JK2 upper layers.



You can't do it, unless the code is in the adapter, and that's bad 
design (it's a protocol feature, so it should be in the protocol hanlder).

Couldn't the compression goes in filter, like Amy does sometimes ago ?


The compression code should go in a filter for HTTP/1.1. For the native 
webserver connector, like JK2, I insist that this is to be done in the 
native code.

Just take an example :

If a servlet has to respond a 100K content, and you're using
webserver+jk via net/ajp13, tomcat will send 100K by the
network which will be compressed 'à la volée' by mod_deflate.

You've got a 100K network use (tc->webserver) + about 30k
network use (webserver->browser).

If you've got the compression done in java side, you'll have
only 30+30 network use and you know that bandwidth today is
more important for IT and ADMINs that CPU/RAM.

May be a solution could be to bench and optimize the Amy works
on gzip compression filter ?

Of course compression may also be present in browser->server,
ie while uploading large file.

When you're using tomcat/jk in SOAP situation, having gzip
activated make operation appears really quickers since the
volume of datas in both side could be important.

Just my 0.01 EUR.



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: gzip-encoding in TC 4.1.x/5.x

2002-12-18 Thread Henri Gomez
One of the problems is that the compressed streams from the JDK are not 
recyclable, cause a lot of possibly synced method calls, and so on. 
Plus, it's kinda ugly to fit the OS and IS models into the Coyote 
HTTP/1.1 filter model.

Does anyone know about compression code which would use byte arrays on 
input/output ?

I could try to make something like this, just tell me what you need.


I hope someone could works on it at the coyote level to make
it available for both HTTP 1.1 and JK2 upper layers.





You can't do it, unless the code is in the adapter, and that's bad 
design (it's a protocol feature, so it should be in the protocol 
hanlder).



Couldn't the compression goes in filter, like Amy does sometimes ago ?



You can use it there if you want. However, transfer encoding is a 
protocol feature. So it seems logical to handle this at the protocol 
layer (for example, chunked is a transfer encoding, and also hanlded at 
the protocol handler level). Plus you get a nice server wide 
configuration on the native webserver, rather than individual settings 
depending on where the resource is served from. It just seems much cleaner.

I agree


I don't quite see the Apache <-> Tomcat link being bandwidth constrained 
except in very specific situations. In loopback, it uses special 
optimized processing, and if there are separate boxes for Apache and 
Tomcat, then they should IMO use a dedicated network link.

Dedicated link, you know what it means say the average IT manager :

DECICATED LINK = A NEW SWITCH + NEW CABLES + NEW SUPERVISION => $/EUR++

If ever you came back to Lyon, I'll make you meet one of my IT manager ;-)


I don't see what you can do to improve Amy's filter performance, as it 
has to:
- be thread safe
- use inefficient methods from the servlet API (which create garbage, etc)

What could we do so ?

- Create a GZIP implementation using byte array
- Use it in HTTP 1.1 stack
- Use it in JK2

As I tell you, I could try to look for or write a GZIP writer 
implementation using byte array, just provide the interfaces.





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 



Re: gzip-encoding in TC 4.1.x/5.x

2002-12-18 Thread Henri Gomez
Did this ZLIB Java implementation could be what you're looking
Remy ?

http://www.jcraft.com/jzlib/index.html


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: gzip-encoding in TC 4.1.x/5.x

2002-12-18 Thread Henri Gomez
Dedicated link, you know what it means say the average IT manager :

DECICATED LINK = A NEW SWITCH + NEW CABLES + NEW SUPERVISION => $/EUR++

If ever you came back to Lyon, I'll make you meet one of my IT manager 
;-)


He's dumb ;-)
Look, you're putting together a cluster. Nothing good will come out of 
saving $50. Also, if you have only one Tomcat srever, you could use a 
crossover cable.

On production site, a 100 Mb switch + cabling and monitoring cost
much more than 50 EUR :)



As I tell you, I could try to look for or write a GZIP writer 
implementation using byte array, just provide the interfaces.


Well, the idea is to be efficient, so:
- Have a ByteChunk compress(ByteChunk) method (assuming that giving it 
an empty chunk means it's the end of the input stream)

Ok, but the compress method will create the returned
ByteChunk and you may want instead :

int compress(ByteChunk src, ByteChunk dst)

Which will make the caller task to create src/dst ByteChunk.


- Have a recycle method


With compress(src, dst), caller make the recycling.


- No object allocation (and esp buffers), except on init


Each using instance will create it's own dst chunk.


- No need to worry about thread safety, so no syncs


Caller decide what to pass.


But it's ok, we can have the first version use the JDK code.


I'll see how we could make use ByteChunk with JDK code for now.



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: gzip-encoding in TC 4.1.x/5.x

2002-12-18 Thread Henri Gomez
Actually, they are both equivalent.


I'll see how we could make use ByteChunk with JDK code for now.



I've already started experimenting.


Thanks to send me a note when code will be available.

I'll could add some code to mimic mod_deflate ie :

- compress only certain type of mimes (ie only text/html)
- desactivate it for some browsers


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/filtersGzipOutputFilter.java

2002-12-19 Thread Henri Gomez
[EMAIL PROTECTED] wrote:

remm2002/12/18 12:36:58

  Modified:http11/src/java/org/apache/coyote/http11 Constants.java
Http11Processor.java Http11Protocol.java
  Added:   http11/src/java/org/apache/coyote/http11/filters
GzipOutputFilter.java
  Log:
  - Add support for gzip content encoding.
  - I believe some broken user agents must be excluded.


Great...

I see another test to add also, to avoid compression if the response
is allready gziped.




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11Http11Processor.java

2002-12-19 Thread Henri Gomez
[EMAIL PROTECTED] wrote:

remm2002/12/19 01:19:06

  Modified:http11/src/java/org/apache/coyote/http11
Http11Processor.java
  Log:
  - Same, but without the tabs ;-)


Oups, sorry.



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: [VOTE] Tomcat 4.1.18 release

2002-12-19 Thread Henri Gomez
+1


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/commonChannelSocket.java

2002-12-19 Thread Henri Gomez
[EMAIL PROTECTED] wrote:

costin  2002/12/19 07:36:32

  Modified:jk/java/org/apache/jk/common ChannelSocket.java
  Log:
  Change log level to debug for "Connection closed". This is a normal
  message that happens quite often for Apache1.3, where each child
  process can restart after a number of requests. This would avoid
  filling the logs.


It's also the case when you're using Apache 2.0



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: j-t-c/util, 3.3 and logging

2002-12-19 Thread Henri Gomez
Larry Isaacs wrote:

I hope to spend some cycles advancing a Tomcat 3.3.2 release
over the holidays.  I'm not assuming I can finish, but hopefully
a Tomcat 3.3.2 release can be made in January.  I'll also try
to get back up to speed with Tomcat 4 & 5 and J-T-C.

I can try to help with the glog factory if I find time before
Bill does.


+1 for 3.3.2



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




JK 1.2.2 need Windows binaries

2003-01-07 Thread Henri Gomez
I just take a look and see that jk 1.2.2 release miss a
binary for Windows (Apache 1.3.x/2.0).

Nacho ?


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




FYI: [Fwd: documentation error]

2003-01-08 Thread Henri Gomez
<<< text/plain; charset=ISO-8859-1; format=flowed: Unrecognized >>>
--- Begin Message ---
I wished to point out that in the jakarta/tomcat documentation, there is an
error.  

Under server configuration reference, Host
(webapps\tomcat-docs\config\host.html), it shows, under the section heading
request filters, an example of using the valve xml tag for the server.xml
configuration file.


  ...
  
  
  ...


The problem is in the regular expression, it should read:


  ...
  
  
  ...


Without the '\w' and the '\d' the server will not start, as the regular
expression engine will throw an exception.

Excellent job, else, guys!  Thanks,

Shawn Stoffer
 <> 



Stoffer, Shawn D.vcf
Description: Binary data
--- End Message ---
--
To unsubscribe, e-mail:   
For additional commands, e-mail: 


Tomcat 4.1.18 rpm available

2003-01-08 Thread Henri Gomez
After some delay the TC 4.1.18 rpms are available at :

http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.1.18/rpms/

Regards


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




  1   2   3   4   5   6   7   8   9   10   >