Re: Ready for mod_jk 1.2.6 release?

[Henri Gomez]

Rainer Jung wrote:
Hi,
the last release of mod_jk 1.2.x (1.2.5) is more than 9 months old. 
Since then there have been important improvements (CPing/CPong and 
recovery_options). Especially recovery_options is very useful in 
transparent administration (start/stop) of cluster nodes.

The 1.2 branch is still the preferred branch for combination with apache 
1.3. Is there any volunteer to make an official 1.2.6 release? I do hope 
so ;-)
I could works on it if nobody else has time to act as release manager.
Feedback welcome of course, especially on possible blocking bugs...
Another good argument: The documentation of the new features is already 
there 
(http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jk2/jk/workershowto.html), 
so no additional work and furthermore, the documentation up to now does 
not mention, that all these features are still not available, because 
1.2.6 has never been released. Many thanks to whoever wrote that document.

I worked with a cvs build under solaris for some weeks without problems, 
but for production purposes people need an official release.

The last changes in the native jk code is more then 6 weeks old and 
there is no code change activity at the moment. So this might be a good 
point in time to release mod_jk 1.2.6.

Looking forward for positive feedback
Rainer Jung
-
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: Re: Ready for mod_jk 1.2.6 release?

[Service Client Fnac.com]

Chère Cliente, Cher Client,

Merci de nous avoir contactés.

Vous venez d'envoyer un message à une adresse ne permettant pas
de recevoir d'e-mail.

Pour trouver les réponses à vos questions sur vos commandes, sur
les produits, sur le site, consultez nos pages d'aide en ligne
en cliquant sur :
http://www.fnac.com/Help/A01.asp

Vous pouvez également suivre en direct l'évolution de vos commandes
en cours, en consultant la rubrique "Vos Commandes en un clin d'oeil"
en cliquant sur :
https://www.fnac.com/Account/Profil/default.asp

Nous espérons que ces pages vous apporteront toutes les informations
nécessaires. Dans le cas contraire, vous pouvez nous contacter par
e-mail en cliquant sur le lien :
http://www.fnac.com/Service_Client/FnacSUGG.asp

Merci de votre fidélité a www.fnac.com

Très cordialement,

L'équipe Fnac.com

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

Re: Ready for mod_jk 1.2.6 release?

[Henri Gomez]

Service Client Fnac.com wrote:
Chère Cliente, Cher Client,
Merci de nous avoir contactés.
Vous venez d'envoyer un message à une adresse ne permettant pas
de recevoir d'e-mail.
Pour trouver les réponses à vos questions sur vos commandes, sur
les produits, sur le site, consultez nos pages d'aide en ligne
en cliquant sur :
http://www.fnac.com/Help/A01.asp
Vous pouvez également suivre en direct l'évolution de vos commandes
en cours, en consultant la rubrique "Vos Commandes en un clin d'oeil"
en cliquant sur :
https://www.fnac.com/Account/Profil/default.asp
Nous espérons que ces pages vous apporteront toutes les informations
nécessaires. Dans le cas contraire, vous pouvez nous contacter par
e-mail en cliquant sur le lien :
http://www.fnac.com/Service_Client/FnacSUGG.asp
Merci de votre fidélité a www.fnac.com
Très cordialement,
Well I don't see why the Client Support of Fnac is subscribed here,
so I strongly suggest mailing list manager to remove it.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Re: Ready for mod_jk 1.2.6 release?

[Service Client Fnac.com]

Chère Cliente, Cher Client,

Merci de nous avoir contactés.

Vous venez d'envoyer un message à une adresse ne permettant pas
de recevoir d'e-mail.

Pour trouver les réponses à vos questions sur vos commandes, sur
les produits, sur le site, consultez nos pages d'aide en ligne
en cliquant sur :
http://www.fnac.com/Help/A01.asp

Vous pouvez également suivre en direct l'évolution de vos commandes
en cours, en consultant la rubrique "Vos Commandes en un clin d'oeil"
en cliquant sur :
https://www.fnac.com/Account/Profil/default.asp

Nous espérons que ces pages vous apporteront toutes les informations
nécessaires. Dans le cas contraire, vous pouvez nous contacter par
e-mail en cliquant sur le lien :
http://www.fnac.com/Service_Client/FnacSUGG.asp

Merci de votre fidélité a www.fnac.com

Très cordialement,

L'équipe Fnac.com

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

AW: Ready for mod_jk 1.2.6 release?

[Hans Schmid]

Hi,

a mod_jk 1.2.6 release would be highly welcome.
We are using cvs head in production for a couple of month now without
problems.

thanks,
Hans


> -Ursprungliche Nachricht-
> Von: Henri Gomez [mailto:[EMAIL PROTECTED]
> Gesendet: Donnerstag, 8. Juli 2004 10:01
> An: Tomcat Developers List
> Betreff: Re: Ready for mod_jk 1.2.6 release?
>
>
> Rainer Jung wrote:
> > Hi,
> >
> > the last release of mod_jk 1.2.x (1.2.5) is more than 9 months old.
> > Since then there have been important improvements (CPing/CPong and
> > recovery_options). Especially recovery_options is very useful in
> > transparent administration (start/stop) of cluster nodes.
> >
> > The 1.2 branch is still the preferred branch for combination
> with apache
> > 1.3. Is there any volunteer to make an official 1.2.6 release?
> I do hope
> > so ;-)
>
> I could works on it if nobody else has time to act as release manager.
>
> Feedback welcome of course, especially on possible blocking bugs...
>
> > Another good argument: The documentation of the new features is already
> > there
> >
> (http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jk2/jk/workershow
> to.html),
> > so no additional work and furthermore, the documentation up to now does
> > not mention, that all these features are still not available, because
> > 1.2.6 has never been released. Many thanks to whoever wrote
> that document.
> >
> > I worked with a cvs build under solaris for some weeks without
> problems,
> > but for production purposes people need an official release.
> >
> > The last changes in the native jk code is more then 6 weeks old and
> > there is no code change activity at the moment. So this might be a good
> > point in time to release mod_jk 1.2.6.
> >
> > Looking forward for positive feedback
> >
> > Rainer Jung
> >
> >
> > -
> > 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]

Re: Ready for mod_jk 1.2.6 release?

[Remy Maucherat]

Henri Gomez wrote:
Well I don't see why the Client Support of Fnac is subscribed here,
so I strongly suggest mailing list manager to remove it.
I'm on a modem this week :/
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Ready for mod_jk 1.2.6 release?

[Henri Gomez]

Henri Gomez wrote:
Rainer Jung wrote:
Hi,
the last release of mod_jk 1.2.x (1.2.5) is more than 9 months old. 
Since then there have been important improvements (CPing/CPong and 
recovery_options). Especially recovery_options is very useful in 
transparent administration (start/stop) of cluster nodes.

The 1.2 branch is still the preferred branch for combination with 
apache 1.3. Is there any volunteer to make an official 1.2.6 release? 
I do hope so ;-)

I could works on it if nobody else has time to act as release manager.
Feedback welcome of course, especially on possible blocking bugs...
Make a build on latest from CVS, and it works on both Linux
Fedora Core 2 and iSeries (AS/400) V5R2.
Could someone works on an Windows version for Apache 2 ?
Regards
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 29914] - StandardServer.storeConfig() not saved DefaultContext Listeners

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=29914

StandardServer.storeConfig() not saved DefaultContext Listeners





--- Additional Comments From [EMAIL PROTECTED]  2004-07-08 08:54 ---
Before we can implemented a better defaultContext support
we must add removeLifecycleListener and findLifecycleListeners.

regards
peter

s. Patch

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

DO NOT REPLY [Bug 29780] - Why we need a jkMain static attibute?

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=29780

Why we need a jkMain static attibute?





--- Additional Comments From [EMAIL PROTECTED]  2004-07-08 08:55 ---
Created an attachment (id=12057)
Better LifecycleListener Support at StandardDefaultContext

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

DO NOT REPLY [Bug 29914] - StandardServer.storeConfig() not saved DefaultContext Listeners

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=29914

StandardServer.storeConfig() not saved DefaultContext Listeners





--- Additional Comments From [EMAIL PROTECTED]  2004-07-08 08:59 ---
Created an attachment (id=12058)
Better LifecycleListenerSupport at DefaultContext

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

DO NOT REPLY [Bug 29780] - Why we need a jkMain static attibute?

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=29780

Why we need a jkMain static attibute?





--- Additional Comments From [EMAIL PROTECTED]  2004-07-08 09:03 ---
sorry! the last attachment is for bug
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=29914

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

DO NOT REPLY [Bug 29914] - StandardServer.storeConfig() not saved DefaultContext Listeners

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=29914

StandardServer.storeConfig() not saved DefaultContext Listeners





--- Additional Comments From [EMAIL PROTECTED]  2004-07-08 09:09 ---
Szenario:
DefaultContext with LifecycleListener info
start context
stop context
start context

Hups:
Now the context have two DefaultContext Listener info

Problem is: That installDefaultContext() called at every context start, but
the DefaultContext LifecycleListener not delete at stop!

Regards
Peter

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

DO NOT REPLY [Bug 29914] - StandardServer.storeConfig() not saved DefaultContext Listeners

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=29914

StandardServer.storeConfig() not saved DefaultContext Listeners





--- Additional Comments From [EMAIL PROTECTED]  2004-07-08 09:20 ---

At which use case the follwing code at
StandardDefaultContext.importDefaultContext() make sense?

   if (!(context instanceof StandardContext)) {
ContextEjb [] contextEjb = findEjbs();

I thing the NamingContextListener transfer all DefaultContext information.
after DefaultContext get the lifecycleEvent.

Strange is the addLocalEjb at NamingContextListener is not yet implemented...

regards
peter

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

DO NOT REPLY [Bug 29971] New: - Commented out page directive is parsed

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=29971

Commented out page directive is parsed

   Summary: Commented out page directive is parsed
   Product: Tomcat 5
   Version: 5.0.25
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


If I have this page:
<[EMAIL PROTECTED] contentType="text/html"%>
<%--<[EMAIL PROTECTED] pageEncoding="ISO-8859-2"%>--%>

JSP Page




Then the second page directive is parsed as well and the response encoding and
the file encoding is ISO-8859-2. It should be ISO-8859-1.

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

DO NOT REPLY [Bug 29971] - Commented out page directive is parsed

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=29971

Commented out page directive is parsed

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Priority|Other   |Medium

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

DO NOT REPLY [Bug 29971] - Commented out page directive is parsed

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=29971

Commented out page directive is parsed

[EMAIL PROTECTED] changed:

   What|Removed |Added

 OS/Version|Other   |Linux
   Platform|Other   |PC

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

[Fwd: Re: What about gzip compression ?]

[Henri Gomez]

Remy ?
--- Begin Message ---
Henri Gomez wrote:
Take a look in jakarta-tomcat-connectors (ie: 
http://apache.fastorama.com/dist/jakarta/tomcat-connectors/jk/source/jakarta-tomcat-connectors-jk-1.2.5-src.tar.gz) 

jakarta-tomcat-connectors\http11\src\java\org\apache\coyote\http11
Thanks, found it in the Http11Processor. However, it seems that the Coyote 
connector doesn't handle the "TE" header. In other words, it doesn't seem to 
support negotiation?

Regards,
Jochen

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

NullPointerException in CoyoteRequestFacade

[Markus Mayer]

Hi all,
we are using tomcat 4.1.27 as a servlet container (no jsp's). when issuing 
several concurrent requests to our servlet we receive a 
NullPointerException from CoyoteRequestFacade (see stacktrace below). This 
is because for some reason the CoyoteRequest instance held by the facade 
gets nulled when several requests are processed by the server. the strange 
thing is however that the facade itself is still a valid reference. its 
just the decorated request instance that disappears. can anybody on the 
list give me any pointers on where to look for a solution?

how is the requestFacade supposed to behave with regard to a servlet 
receiving concurrent requests? is it a valid implementation strategy to 
add attributes to a HttpServletRequest instance in a filter, then pass the 
request to the servlet and afterwards process the request (and its 
attributes) again in the filter after the servlet has finished processing 
the request (after calling getChain().doFilter())?

Any help appreciated.

Thanks,
Markus

p.s.: i hope it is ok to post this question to the dev mailing list. if i 
chose the wrong list please drop me a line...

at org.apache.coyote.tomcat4.CoyoteRequestFacade.setAttribute 
(CoyoteRequestFacade.java: 234)
at com.generali.vp.tomcat.AbstractAdapterServlet.sendOutputToBrowser 
(AbstractAdapterServlet.java: 222)
at com.generali.vp.tomcat.evpbasis.AbstractEVPServlet.doPost 
(AbstractEVPServlet.java: 154)
at javax.servlet.http.HttpServlet.service (HttpServlet.java: 760)
at javax.servlet.http.HttpServlet.service (HttpServlet.java: 853)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter 
(ApplicationFilterChain.java: 247)
at org.apache.catalina.core.ApplicationFilterChain.doFilter 
(ApplicationFilterChain.java: 193)
at com.generali.vp.filters.AbstractFilter.doFilter 
(AbstractFilter.java: 94)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter 
(ApplicationFilterChain.java: 213)
at org.apache.catalina.core.ApplicationFilterChain.doFilter 
(ApplicationFilterChain.java: 193)
at com.generali.vp.filters.AbstractFilter.doFilter 
(AbstractFilter.java: 94)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter 
(ApplicationFilterChain.java: 213)
at org.apache.catalina.core.ApplicationFilterChain.doFilter 
(ApplicationFilterChain.java: 193)
at com.generali.vp.filters.AbstractFilter.doFilter 
(AbstractFilter.java: 94)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter 
(ApplicationFilterChain.java: 213)
at org.apache.catalina.core.ApplicationFilterChain.doFilter 
(ApplicationFilterChain.java: 193)
at com.generali.vp.filters.AbstractFilter.doFilter 
(AbstractFilter.java: 94)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter 
(ApplicationFilterChain.java: 213)
at org.apache.catalina.core.ApplicationFilterChain.doFilter 
(ApplicationFilterChain.java: 193)
at com.generali.vp.filters.AbstractFilter.doFilter 
(AbstractFilter.java: 94)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter 
(ApplicationFilterChain.java: 213)
at org.apache.catalina.core.ApplicationFilterChain.doFilter 
(ApplicationFilterChain.java: 193)
at com.generali.vp.filters.AbstractFilter.doFilter 
(AbstractFilter.java: 94)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter 
(ApplicationFilterChain.java: 213)
at org.apache.catalina.core.ApplicationFilterChain.doFilter 
(ApplicationFilterChain.java: 193)
at com.generali.vp.filters.AbstractFilter.doFilter 
(AbstractFilter.java: 94)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter 
(ApplicationFilterChain.java: 213)
at org.apache.catalina.core.ApplicationFilterChain.doFilter 
(ApplicationFilterChain.java: 193)
at com.generali.vp.filters.AbstractFilter.doFilter 
(AbstractFilter.java: 94)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter 
(ApplicationFilterChain.java: 213)
at org.apache.catalina.core.ApplicationFilterChain.doFilter 
(ApplicationFilterChain.java: 193)
at com.generali.vp.filters.AbstractFilter.doFilter 
(AbstractFilter.java: 94)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter 
(ApplicationFilterChain.java: 213)
at org.apache.catalina.core.ApplicationFilterChain.doFilter 
(ApplicationFilterChain.java: 193)
at com.generali.vp.filters.AbstractFilter.doFilter 
(AbstractFilter.java: 94)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter 
(ApplicationFilterChain.java: 213)
at org.apache.catalina.core.ApplicationFilterChain.doFilter 
(ApplicationFilterChain.java: 193)
at com.generali.vp.filters.AbstractFilter.doFilter 
(AbstractFilter.java: 94)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter 
(ApplicationFilterChain.java: 213)
at org.apache.catalina.core.ApplicationFilterChain.doFilter 
(ApplicationFilterChain.java: 193)
at com.g

Re: Ready for mod_jk 1.2.6 release?

[jean-frederic clere]

Henri Gomez wrote:
Rainer Jung wrote:
Hi,
the last release of mod_jk 1.2.x (1.2.5) is more than 9 months old. 
Since then there have been important improvements (CPing/CPong and 
recovery_options). Especially recovery_options is very useful in 
transparent administration (start/stop) of cluster nodes.

The 1.2 branch is still the preferred branch for combination with 
apache 1.3. Is there any volunteer to make an official 1.2.6 release? 
I do hope so ;-)

I could works on it if nobody else has time to act as release manager.
Feedback welcome of course, especially on possible blocking bugs...
I am porting it to my favorite EBCDIC mainframe and I still need sometime to get 
it working.


Another good argument: The documentation of the new features is 
already there 
(http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jk2/jk/workershowto.html), 
so no additional work and furthermore, the documentation up to now 
does not mention, that all these features are still not available, 
because 1.2.6 has never been released. Many thanks to whoever wrote 
that document.

I worked with a cvs build under solaris for some weeks without 
problems, but for production purposes people need an official release.

The last changes in the native jk code is more then 6 weeks old and 
there is no code change activity at the moment. So this might be a 
good point in time to release mod_jk 1.2.6.

Looking forward for positive feedback
Rainer Jung
-
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]

DO NOT REPLY [Bug 29966] - the servlet code generated from jsp always have new line code

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=29966

the servlet code generated from jsp always have new line code

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2004-07-08 10:46 ---
This is a call for help. Bugzilla is not a help forum. Please use the
tomcat-user list for help.

Otherwise, see the trimSpaces option in JspServlet in CATALINA_HOME/conf/web.xml.

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

DO NOT REPLY [Bug 28219] - Dolar sign in password of JNDI-Datasource disappears

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=28219

Dolar sign in password of JNDI-Datasource disappears





--- Additional Comments From [EMAIL PROTECTED]  2004-07-08 11:40 ---
The same problem exists with the driverClassName. We using the 
JData2_0.sql.$Driver from JDataConnect. It only works when we write double $$ 
signs directly in the server.xml:


  driverClassName
  JData2_0.sql.$$Driver
 

But after saving the server.xml through the admin webapp, one of the two $ 
disappeared. And Tomcat looks after then for a class called JData2_0.sql.Driver 
instead of JData2_0.sql.$Driver.

We cant use the admin webapp because of this bug.

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

Hin Kan Lee/Prymnewey is out of the office.

[Hinkan]

I will be out of the office starting  07/05/2004 and will not return until
07/13/2004.

I will respond to your message when I return.



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

DO NOT REPLY [Bug 28219] - Dolar sign in password of JNDI-Datasource disappears

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=28219

Dolar sign in password of JNDI-Datasource disappears





--- Additional Comments From [EMAIL PROTECTED]  2004-07-08 13:14 ---
This is a diegster side effect.

With Tomcat 5.x you can used all system properties variable inside
server.xml or context.xml. But with one "$" the Diegster interpreter
you $Driver as empty variable...

Your "$$" trick work not really. The StandardServer.storeConfig save the actual
memory state from Tomcat. Admin used this method and your problem comes back.

Sorry, but currently you have no chance to used Admin app with your configuration.

regards.
Peter

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

DO NOT REPLY [Bug 29975] New: - Workaround for bug in IE when fetching documents over HTTPS

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=29975

Workaround for bug in IE when fetching documents over HTTPS

   Summary: Workaround for bug in IE when fetching documents over
HTTPS
   Product: Tomcat 5
   Version: 5.0.25
  Platform: All
   URL: http://support.microsoft.com/?id=316431
OS/Version: All
Status: NEW
  Severity: Major
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


when I configure a web application with the user data constraint set to 
confidential, so that tomcat enforces HTTPS access and then try to download a 
PDF document using InternetExplorer, the document cannot be displayed due to a 
bug within IE. The above URL describes the bug but tells that it is "by design" 
(as all Microsoft bugs are ;) ).

The problem occurs because tomcat adds the following two HTTP headers, if and 
only if a webapp has a user-data constraint of confidential:

Pragma: no-cache
Cache-control: no-cache,max-age=0,must-revalidate

I need to secure my web application and I need to workaround this IE bug on the 
server side. Tomcat 4.x does not cause the problem, but tomcat5.x does.

It is not a safe solution to remove the respective http headers within a filter 
because the filter would have to do this after the filterchain invocation and 
the outputstream could already have been committed at that time.

Another way would be to add a filter which tests whether a request is HTTP and 
then manually redirects to HTTPS and then dropping the user-data-constraint 
from the web-descriptor.

Since nearly all IE browsers have this bug, this means that unless tomcat 
provides a workaround solution for this, developers will not be able to 
facilitate the standard way specifying security constraints.

Any ideas for a short-time workaround that I could apply would be very welcome 
since I need to get this fixed quickly...

Thanks

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

Re: Ready for mod_jk 1.2.6 release?

[Jess Holle]

Ditto.  I started just using CVS-latest for mod_jk and mod_jk2 some time 
back as the gap between new, stable feature/fix content and release 
labels was just too great.  Overall CVS-latest has been more stable than 
the last labels for some time now

David Rees wrote:
Rainer Jung wrote:
 

the last release of mod_jk 1.2.x (1.2.5) is more than 9 months old.
Since then there have been important improvements (CPing/CPong and
recovery_options). Especially recovery_options is very useful in
transparent administration (start/stop) of cluster nodes.
   

I would like to see one.  I am already using CVS to get the new features
and bug fixes, but an official release would be nice.
-Dave
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

Re: Ready for mod_jk 1.2.6 release?

[jean-frederic clere]

jean-frederic clere wrote:
Henri Gomez wrote:
Rainer Jung wrote:
Hi,
the last release of mod_jk 1.2.x (1.2.5) is more than 9 months old. 
Since then there have been important improvements (CPing/CPong and 
recovery_options). Especially recovery_options is very useful in 
transparent administration (start/stop) of cluster nodes.

The 1.2 branch is still the preferred branch for combination with 
apache 1.3. Is there any volunteer to make an official 1.2.6 release? 
I do hope so ;-)

I could works on it if nobody else has time to act as release manager.
Feedback welcome of course, especially on possible blocking bugs...

I am porting it to my favorite EBCDIC mainframe and I still need 
sometime to get it working.

I have 2 unresolved: snprintf and vsnprintf. With Apache-2.0 we should use 
apr_snprintf and apr_vsnprintf for Apache-1.3 should I add "ersatz" routines?


Another good argument: The documentation of the new features is 
already there 
(http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jk2/jk/workershowto.html), 
so no additional work and furthermore, the documentation up to now 
does not mention, that all these features are still not available, 
because 1.2.6 has never been released. Many thanks to whoever wrote 
that document.

I worked with a cvs build under solaris for some weeks without 
problems, but for production purposes people need an official release.

The last changes in the native jk code is more then 6 weeks old and 
there is no code change activity at the moment. So this might be a 
good point in time to release mod_jk 1.2.6.

Looking forward for positive feedback
Rainer Jung
-
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]


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

DO NOT REPLY [Bug 29979] New: - mod_jk 1.2.5 win32 binary is not 1.2.5

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=29979

mod_jk 1.2.5 win32 binary is not 1.2.5

   Summary: mod_jk 1.2.5 win32 binary is not 1.2.5
   Product: Tomcat 5
   Version: Unknown
  Platform: PC
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Native:JK
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


On the downloads page, the alleged mod_jk_1.2.5_1.3.27.dll is not, in fact,
1.2.5 - it's 1.2.4 built against some previous version of apache. Ditto for
mod_jk_1.2.5_2.0.47.dll.

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

DO NOT REPLY [Bug 29975] - Workaround for bug in IE when fetching documents over HTTPS

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=29975

Workaround for bug in IE when fetching documents over HTTPS

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2004-07-08 19:42 ---


*** This bug has been marked as a duplicate of 27122 ***

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

DO NOT REPLY [Bug 27122] - IE plugins cannot access components through Tomcat 5 over SSL

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=27122

IE plugins cannot access components through Tomcat 5 over SSL

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2004-07-08 19:42 ---
*** Bug 29975 has been marked as a duplicate of this bug. ***

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

Re: [Fwd: Re: What about gzip compression ?]

[Remy Maucherat]

Henri Gomez wrote:
Remy ?
Henri Gomez wrote:
Take a look in jakarta-tomcat-connectors (ie: 
http://apache.fastorama.com/dist/jakarta/tomcat-connectors/jk/source/jakarta-tomcat-connectors-jk-1.2.5-src.tar.gz) 

jakarta-tomcat-connectors\http11\src\java\org\apache\coyote\http11

Thanks, found it in the Http11Processor. However, it seems that the 
Coyote connector doesn't handle the "TE" header. In other words, it 
doesn't seem to support negotiation?
I intended to use that at first, but actually realized the browsers 
don't use that. Since the simple way of doing compression works with (I 
think) every decent client, I decided to remove the fancy handling of 
negociation I had coded (given the way the filters work and can be 
stacked, it's obvious that I did them that way for that reason).

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

[GUMP@brutus]: jakarta-tomcat-5/jakarta-tomcat-5 failed

[bobh]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact folk at [EMAIL PROTECTED]

Project jakarta-tomcat-5 has an issue affecting its community integration.
Project State : 'Failed', Reason 'Build Failed'

Full details are available at:

http://brutus.apache.org:8080/gump/jakarta-tomcat-5/jakarta-tomcat-5/index.html

That said, some snippets follow:


The following annotations were provided:
 -DEBUG- Jar [naming-resources.jar] identifier set to jar basename: [naming-resources]
 -DEBUG- Jar [servlets-default.jar] identifier set to jar basename: [servlets-default]
 -DEBUG- Jar [naming-common.jar] identifier set to jar basename: [naming-common]
 -DEBUG- Jar [catalina.jar] identifier set to jar basename: [catalina]
 -DEBUG- Jar [bootstrap.jar] identifier set to jar basename: [bootstrap]
 -DEBUG- Jar [servlets-common.jar] identifier set to jar basename: [servlets-common]
 -DEBUG- Jar [servlets-invoker.jar] identifier set to jar basename: [servlets-invoker]
 -INFO- Dependency on javamail exists, no need to add for property mail.jar.
 -INFO- Dependency on jaf exists, no need to add for property activation.jar.
 -INFO- Dependency on jakarta-servletapi-5-servlet exists, no need to add for property 
servlet-api.jar.
 -INFO- Dependency on jakarta-servletapi-5-jsp exists, no need to add for property 
jsp-api.jar.
 -INFO- Dependency on xml-xerces exists, no need to add for property xercesImpl.jar.
 -INFO- Dependency on xml-xerces exists, no need to add for property xml-apis.jar.
 -INFO- Dependency on jakarta-tomcat-util exists, no need to add for property 
tomcat-util.jar.
 -INFO- Dependency on commons-el exists, no need to add for property commons-el.jar.
 -INFO- Dependency on commons-logging exists, no need to add for property 
commons-logging-api.jar.
 -INFO- Dependency on commons-modeler exists, no need to add for property 
commons-modeler.jar.
 -INFO- Dependency on ant exists, no need to add for property ant.home.
 -INFO- Dependency on jsse exists, no need to add for property jsse.home.
 -INFO- Dependency on jmx exists, no need to add for property jmx.home.
 -INFO- Dependency on jmx exists, no need to add for property jmx.jar.
 -INFO- Dependency on jmx exists, no need to add for property jmx-tools.jar.
 -INFO- Dependency on jndi exists, no need to add for property jndi.home.
 -INFO- Dependency on jakarta-regexp exists, no need to add for property regexp.home.
 -INFO- Dependency on jakarta-regexp exists, no need to add for property regexp.jar.
 -INFO- Dependency on javamail exists, no need to add for property mail.home.
 -INFO- Dependency on jakarta-tomcat-coyote exists, no need to add for property 
tomcat-coyote.home.
 -INFO- Dependency on jakarta-tomcat-jasper_tc5 exists, no need to add for property 
jasper.home.
 -INFO- Dependency on jaf exists, no need to add for property activation.home.
 -INFO- Dependency on commons-modeler exists, no need to add for property 
commons-modeler.home.
 -INFO- Dependency on commons-daemon exists, no need to add for property 
commons-daemon.jsvc.tar.gz.
 -INFO- Dependency on jakarta-struts exists, no need to add for property struts.home.
 -INFO- Enable "debug" output, due to a sequence of 7 previous errors.
 -INFO- Failed with reason build failed


The following work was performed:
http://brutus.apache.org:8080/gump/jakarta-tomcat-5/jakarta-tomcat-5/gump_work/build_jakarta-tomcat-5_jakarta-tomcat-5.html
Work Name: build_jakarta-tomcat-5_jakarta-tomcat-5 (Type: Build)
State: Failed
Elapsed: 0 hours, 0 minutes, 29 seconds
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main -debug 
-Dgump.merge=/usr/local/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only 
-Dtomcat33.home=*Unset* 
-Djsp-api.jar=/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr152/dist/lib/jsp-api.jar
 -Djmx.jar=/usr/local/gump/packages/jmx-1_2-ri/lib/jmxri.jar 
-Djmx.home=/usr/local/gump/packages/jmx-1_2-ri 
-Djdbc20ext.jar=/usr/local/gump/packages/jdbc2_0/jdbc2_0-stdext.jar 
-Dregexp.jar=/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-20040708.jar
 -Dmail.home=/usr/local/gump/packages/javamail-1.3 
-Dant.home=/usr/local/gump/public/workspace/ant/dist 
-Dsite2.home=/usr/local/gump/public/workspace/jakarta-site2 
-Dcommons-collections.jar=/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-20040708.jar
 -Dxml-apis.jar=/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar 
-DxercesImpl.jar=/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl

Request for Inputs for a Design/Architecture for VXML Application Server

[Darshan Rawal]

We implement a Messaging PLatform for Voice Applications.
Our current platform has 2 Major Components as shown below:-

Media Server <--- MML/TCP-IP ---> Application Server.

We want to move to a new architecture for our Application Server where
the interaction between App Server and Media Server is as shown
below(i.e. based on VXML over HTTP)

Media Server <--- VXML/HTTP ---> Application Server.

To achieve this goal we need to implement an "VXML Document Server",
which will generate VXML
(Voice XML) pages based on the business logic & Data access layers
within the Application server.

We have 2 options to implement the VXML document Server:-

1) USing the J2EE presentation tier(i.e. JSP & Servlets)
2) Writing our own VXML generation module in C++ based(probably based
on the JAVA Servlet paradigm).

Our Factors while deciding between the 2 would be as follows:-

1) Performance(This is the key for us, we ezpecially need to know
exactly how slow JAVA is as Compared to C++)
2) Integration with our Business logic & Data Access Layers.(All our
business logic & data access is written in C/C++. Hence if we chose
JAVA, then we might have to use JNI or make use of TCP/IP to
communicate with our different Processes written in C/C++)
3) Ease of Future Change(We want to develop new Application Features
Quickly & fast).
4) Fast & better Development environment.

I am a proponent of the use of Tomcat Servlet Container and hence the
use of J2EE front end for our module. But I was hoping to get some
pointers from you all, just in case somebody might have implemented
something similiar or might just have some inputs nevertheless.

We are in a time crunch here, as we have to make a decision by next Monday end.

Thanks in advance.

Regards,

Darshan.

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

Re: Request for Inputs for a Design/Architecture for VXML Application Server

[Peter Lin]

from where I am sitting, sounds like the project doesn't have enough
information to make a good decision. Why move from MML/TCP to
VXML/HTTP?

if you read my performance article on the resources page, XML is very
CPU and memory intensive. Even with XStream java-xml binding library,
handling moderate concurrent load will easily consume 100% of the CPU.
 if you're serious about using VXML/HTTP, you're going to have to use
some kind of hardware acceleration to get wire speed.

even without implementing a single line of code, I can tell you right
now it is going to be really hard scaling VXML/HTTP to handle 50
concurrent streams. On a 3ghz cpu, 30 concurrent stream will consume
100% of the CPU. With a 2.4ghz CPU, 10-15 concurrent xml parsers will
consume 60-75% of the CPU regardless of the platform. it doesn't
matter if you write it in C#, C++, C or Java.  I keep a pretty close
watch on XML technology and most of the parsers today are about the
same. the differences are not significant to me.

given the primary limitation is CPU consumption, your options for
application server should be based on reliability, maturity and
toolset. If J2EE provides the features and scalability you need, then
use it. If writing your own application server in C++ is the best
option, then find two guys who have 10 years of experience writing
high performance app servers.

I would guess using servlets/jsp is the least of your concerns at this
point. Until you have the VXML driver written and know it's
performance characteristics, any decision on app server will be
premature. You may want to look at Xml Pull Parser3, XStream, Jixb,
XBis and the new xml stream parser.

do a quick implementation for VXML and see what kind of performance
you get. if that is sufficient, you can move on. otherwise, you may
have to write a highly optimized VXML parser in C using a finite state
machine of some sort. good luck

peter


On Thu, 8 Jul 2004 18:19:23 -0700, Darshan Rawal <[EMAIL PROTECTED]> wrote:
> We implement a Messaging PLatform for Voice Applications.
> Our current platform has 2 Major Components as shown below:-
> 
> Media Server <--- MML/TCP-IP ---> Application Server.
> 
> We want to move to a new architecture for our Application Server where
> the interaction between App Server and Media Server is as shown
> below(i.e. based on VXML over HTTP)
> 
> Media Server <--- VXML/HTTP ---> Application Server.
> 
> To achieve this goal we need to implement an "VXML Document Server",
> which will generate VXML
> (Voice XML) pages based on the business logic & Data access layers
> within the Application server.
> 
> We have 2 options to implement the VXML document Server:-
> 
> 1) USing the J2EE presentation tier(i.e. JSP & Servlets)
> 2) Writing our own VXML generation module in C++ based(probably based
> on the JAVA Servlet paradigm).
> 
> Our Factors while deciding between the 2 would be as follows:-
> 
> 1) Performance(This is the key for us, we ezpecially need to know
> exactly how slow JAVA is as Compared to C++)
> 2) Integration with our Business logic & Data Access Layers.(All our
> business logic & data access is written in C/C++. Hence if we chose
> JAVA, then we might have to use JNI or make use of TCP/IP to
> communicate with our different Processes written in C/C++)
> 3) Ease of Future Change(We want to develop new Application Features
> Quickly & fast).
> 4) Fast & better Development environment.
> 
> I am a proponent of the use of Tomcat Servlet Container and hence the
> use of J2EE front end for our module. But I was hoping to get some
> pointers from you all, just in case somebody might have implemented
> something similiar or might just have some inputs nevertheless.
> 
> We are in a time crunch here, as we have to make a decision by next Monday end.
> 
> Thanks in advance.
> 
> Regards,
> 
> Darshan.
> 
> -
> 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: Request for Inputs for a Design/Architecture for VXML Application Server

[Darshan Rawal]

Hello Peter,

Nice to know that somebody replied. Was really desperate to get some inputs!!
My replies are included below.

On Thu, 8 Jul 2004 21:39:23 -0400, Peter Lin <[EMAIL PROTECTED]> wrote:
> from where I am sitting, sounds like the project doesn't have enough
> information to make a good decision. Why move from MML/TCP to
> VXML/HTTP?

This is a requirement from some of our customers. They want to
integrate with any 3rd party Media Server(which all talk VXML).

> 
> if you read my performance article on the resources page, XML is very
> CPU and memory intensive. Even with XStream java-xml binding library,
> handling moderate concurrent load will easily consume 100% of the CPU.
> if you're serious about using VXML/HTTP, you're going to have to use
> some kind of hardware acceleration to get wire speed.

I completely agree on this, but this interpretation of VXML pages is
going to happen on the Media Server side. Hence as of now I am just
concerned with generation of VXML pages and transporting them to the
Media Server, where the CPU intensive XML parsing is going to happen.

> 
> even without implementing a single line of code, I can tell you right
> now it is going to be really hard scaling VXML/HTTP to handle 50
> concurrent streams. On a 3ghz cpu, 30 concurrent stream will consume
> 100% of the CPU. With a 2.4ghz CPU, 10-15 concurrent xml parsers will
> consume 60-75% of the CPU regardless of the platform. it doesn't
> matter if you write it in C#, C++, C or Java.  I keep a pretty close
> watch on XML technology and most of the parsers today are about the
> same. the differences are not significant to me.

We are currently utilizing a 650MHz Sun Sparc Blade & Solaris 8 Core
OS, and it will remain the same for the next release, hence I know
that CPU load will be a reasonable main concern.

> 
> given the primary limitation is CPU consumption, your options for
> application server should be based on reliability, maturity and
> toolset. If J2EE provides the features and scalability you need, then
> use it. If writing your own application server in C++ is the best
> option, then find two guys who have 10 years of experience writing
> high performance app servers.

Our entire Engineering team has reasonablly well knowledge of
C++/C.(not so much of JAVA).Also, complete development is going to be
done by our team.
We are a part of the architecture team which has to decide the
approach to take, and I was just looking for some pointer on that
issue(especially related to the performance implications for JAVA).

> 
> I would guess using servlets/jsp is the least of your concerns at this
> point. Until you have the VXML driver written and know it's
> performance characteristics, any decision on app server will be
> premature. You may want to look at Xml Pull Parser3, XStream, Jixb,
> XBis and the new xml stream parser.
> 
> do a quick implementation for VXML and see what kind of performance
> you get. if that is sufficient, you can move on. otherwise, you may
> have to write a highly optimized VXML parser in C using a finite state
> machine of some sort. good luck
> 
> peter
> 

An prototype of a VXML browser in the Media Server has already been
implemeted. It does have some performance issues. But, as I said
earlier this is not our main concern as of now. The questions that we
have related to taking the approaches are as follows:-

1) Would JAVA be a performance hit in terms of CPU
utilization(especially bcos of the JVM) ? Note that our VXML document
server is not the one doing a lot of CPU intensive operations, it will
be our legacy application written in C/C++.
Also, we are not doing significant CPU intensive operation like math
operations, number crunching, encryption, etc. Would JIT provide
reasonable performance compared to C/C+, by probably consuming more
memory(which we can spare) ?

2) How involving is the work related to integrating a JSP/Servlet
based front end to legacy C/C++ code using JNI(debugging, performance
issues ??) and/or TCP/IP sockets(performance Hit) ?

Thanks & Regards,

- Darshan.


> On Thu, 8 Jul 2004 18:19:23 -0700, Darshan Rawal <[EMAIL PROTECTED]> wrote:
> > We implement a Messaging PLatform for Voice Applications.
> > Our current platform has 2 Major Components as shown below:-
> >
> > Media Server <--- MML/TCP-IP ---> Application Server.
> >
> > We want to move to a new architecture for our Application Server where
> > the interaction between App Server and Media Server is as shown
> > below(i.e. based on VXML over HTTP)
> >
> > Media Server <--- VXML/HTTP ---> Application Server.
> >
> > To achieve this goal we need to implement an "VXML Document Server",
> > which will generate VXML
> > (Voice XML) pages based on the business logic & Data access layers
> > within the Application server.
> >
> > We have 2 options to implement the VXML document Server:-
> >
> > 1) USing the J2EE presentation tier(i.e. JSP & Servlets)
> > 2) Writing our own VXML generation module in C++ based(p

DO NOT REPLY [Bug 25526] - tomcat parses the query string parameters as iso-8859-1

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=25526

tomcat parses the query string parameters as iso-8859-1





--- Additional Comments From [EMAIL PROTECTED]  2004-07-09 02:03 ---
Sorry - but I am still confused: in your comment, in point number 1 you say that
there is useBodyEncodingForURI parameter for Cayote that for TC4 defaults to true. 

In the second point you say that Cayote has URIEncoding parameter which is set
to ISO-8859-1 and in the third point you mention that the URIEncoding parameter
is used to parse the URL parameters (by default).

>From you points I do not understand what is the purpose of the
useBodyEncodingForURI and when is it used by Tomcat?

In TC4, the behaviour that we are seeing is that the URL parameters are parsed
using ISO-8859-1 even of the request.setCharacterEncoding() is called with "UTF-8".

Is there a way to configure Tomcat 4 and 5 (hopefully without calling
Tomcat/Cayote specific methods on objects at runtime) which will force the URL
Parameters to be parsed using the encoding of the body?

The reason I am after this, is that sometimes there is a need to send a browser
redirect passing parameters. A redirect always results in a GET HTTP request
from the browser. I would prefer not to use the session to store the parameters.

Thanks for all your help and information!

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

Re: Request for Inputs for a Design/Architecture for VXML Application Server

[Peter Lin]

On Thu, 8 Jul 2004 18:59:23 -0700, Darshan Rawal <[EMAIL PROTECTED]> wrote:
> Hello Peter,
> 
> 
> I completely agree on this, but this interpretation of VXML pages is
> going to happen on the Media Server side. Hence as of now I am just
> concerned with generation of VXML pages and transporting them to the
> Media Server, where the CPU intensive XML parsing is going to happen.

ok, so if I understand the setup correctly. the app server will only
generate VXML and not consume it. If that is the case, CPU usage
should not be an issue. For detailed information about XML generation
performance, google for XML articles by Dennis Sosnoski. He has
written up detailed articles in the past on xml parsers and xml
binding parser.

> We are currently utilizing a 650MHz Sun Sparc Blade & Solaris 8 Core
> OS, and it will remain the same for the next release, hence I know
> that CPU load will be a reasonable main concern.
> 

Having done stress testing with XML on Solaris systems: 280R, X1,
UltraSparc5, as long as you're not consuming XML, CPU should not be an
issue. Since XML is very verbose and Sun blades typically come with 2
or 4 ethernet ports, I would recommend separating the network traffic
so the XML uses a dedicated router to the media server.

> 
> Our entire Engineering team has reasonablly well knowledge of
> C++/C.(not so much of JAVA).Also, complete development is going to be
> done by our team.
> We are a part of the architecture team which has to decide the
> approach to take, and I was just looking for some pointer on that
> issue(especially related to the performance implications for JAVA).
> 

when you say performance implications, what do you mean? high
concurrent load? memory usage? I/O? threading? the context plays a big
factor in whether or not there will be any issues.

> An prototype of a VXML browser in the Media Server has already been
> implemeted. It does have some performance issues. But, as I said
> earlier this is not our main concern as of now. The questions that we
> have related to taking the approaches are as follows:-
> 
> 1) Would JAVA be a performance hit in terms of CPU
> utilization(especially bcos of the JVM) ? Note that our VXML document
> server is not the one doing a lot of CPU intensive operations, it will
> be our legacy application written in C/C++.
> Also, we are not doing significant CPU intensive operation like math
> operations, number crunching, encryption, etc. Would JIT provide
> reasonable performance compared to C/C+, by probably consuming more
> memory(which we can spare) ?

since the app server is just producing the content, my guess is it's
unlikely there will be any issues beyond concurrency requirements.
since it's media, I'm assuming the servlet will produce a stream of
data. You're probably going to have to use some sort of stream
conversion to reduce memory usage. Regardless of the storage medium, I
wouldn't recommend using DOM and would strongly suggest using the new
xml stream parser/api.

> 
> 2) How involving is the work related to integrating a JSP/Servlet
> based front end to legacy C/C++ code using JNI(debugging, performance
> issues ??) and/or TCP/IP sockets(performance Hit) ?
> 
> Thanks & Regards,
> 
> - Darshan.

I have no experience in JNI beyond reading examples and looking at the
API/specs, so I can't provide anything useful there. You definitely
can get good performance with JNI. Many servlet and EJB containers use
JNI to call native network libs. Resin, weblogic and websphere all use
it, so JNI won't be an issue. I hope that helps.

peter

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

DO NOT REPLY [Bug 29989] New: - jni of mod_jk2 doesn't work for win32 at all

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=29989

jni of mod_jk2 doesn't work for win32 at all

   Summary: jni of mod_jk2 doesn't work for win32 at all
   Product: Tomcat 5
   Version: 5.0.0
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Blocker
  Priority: Other
 Component: Native:JK
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I'm using Win2kServer + Apache2.0.50 + Tomcat5.0.16 (or 5.0.25) + jk2-2.0.4-
win32-apache2.0.49.
After I copied mod_jk2.so (comes from jk2-2.0.4-win32-apache2.0.49) to 
${APACHE2_HOME}/modules, and finish all necessary configurations, start Apache2 
service, I got these messages from ${APACHE2_HOME}/logs/error.log:

[Fri Jul 09 12:06:20 2004] [notice] Parent: Created child process 444
[Fri Jul 09 12:06:20 2004] [notice] Child 444: Child process is running
[Fri Jul 09 12:06:20 2004] [error] workerEnv.initChannel() init failed for 
channel.jni:jni
[Fri Jul 09 12:06:20 2004] [error] workerEnv.initWorkers() init failed for 
worker.jni:onStartup
[Fri Jul 09 12:06:20 2004] [error] workerEnv.initWorkers() init failed for 
worker.jni:onShutdown
[Fri Jul 09 12:06:20 2004] [notice] Child 444: Acquired the start mutex.
[Fri Jul 09 12:06:20 2004] [notice] Child 444: Starting 100 worker threads.

so, as a result, the jni can not work.
I spent lot of time trying to solve the problem, but nothing happens.
Finally, I decide to look for the jk2 source code, see what's the matter of 
that.
Then, I found the following code in jakarta-tomcat-connectors-jk2-2.0.4-
src\jk\native2\server\apache2\mod_jk2.c:608 -

...
if (workerEnv->maxDaemons < 2) {
workerEnv->childId = proc.pid; //  HERE IS IT!!
env->l->jkLog(env, env->l, JK_LOG_INFO,
  "jk2_init() Setting scoreboard slot 0 for child %d\n",
  proc.pid);
}
...

but, in jakarta-tomcat-connectors-jk2-2.0.4-src\jk\native2
\common\jk_channel_jni.c:91 -

...
if (wEnv->childId != 0) { // AND THIS ??
if (jniW->worker != NULL)
jniW->worker->mbean->disabled = JK_TRUE;
return JK_ERR;
}
...

That's it.
So, I chang it to -
...
if (workerEnv->maxDaemons < 2) {
workerEnv->childId = 0; //  HERE IS IT!!
env->l->jkLog(env, env->l, JK_LOG_INFO,
  "jk2_init() Setting scoreboard slot 0 for child %d\n",
  proc.pid);
}
...

I don't really know what it means, but it works for me now   :)

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

DO NOT REPLY [Bug 29485] - Undeploy considered dangerous

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=29485

Undeploy considered dangerous





--- Additional Comments From [EMAIL PROTECTED]  2004-07-09 05:30 ---
Is it possible to create confirm page without JavaScript? I use manager 
application via lynx

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