DO NOT REPLY [Bug 39088] - StandardWrapper getRootCause() infinite loop

[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=39088





--- Additional Comments From [EMAIL PROTECTED]  2006-10-04 02:05 ---
This issue has caused a production incident for us. It was rather tough to debug
given the fact that one would not expect that a getRootCause() method in a
non-Tomcat exception actually implements a (hidden) Tomcat interface. IMHO this
is very bad style.

A recursion detector does not address these issues:
1. Tomcat has no business calling a getRootCause() method in user code. That
method may have a very different contract than what Tomcat expects. It may have
side effects or it may be illegal to call the method in some cases. Because it
is not clear to a user that his getRootCause() method is called by Tomcat and
because exception paths are usually not tested that well, production incidents
are likely to still happen to some users.
2. The user still does not know that he is implementing a hidden Tomcat 
interface.
3. 20 recursions (or any arbitrary number) of reflection, with calls to a method
of unknown specifications may cause performance issues.

I believe that a similar fix to the one for bug 37038 is the best solution. That
fix would result in code that does not surprise Java developers, without the
problems outlined above. It is also unlikely that it would result in breakage,
since I don't think that it's likely that anyone took advantage of this
'feature' to implement some functionality.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Re: [VOTE] Tomcat 4.1.34 Stability

[Yoav Shapira]

Hi,
+1 / Stable, based on limited testing on my behalf.  The license bits
look fine, the checksums and PGP signatures look fine, building from
source worked OK, the examples worked OK, and I ran one of my old apps
on it for a few minutes with a JMeter script testing it.  I don't know
if any of my tests specifically targeted regressions around the areas
where bugs where fixed.

Yoav

On 10/3/06, Mark Thomas <[EMAIL PROTECTED]> wrote:

Mark Thomas wrote:
> Apache Tomcat 4.1.34 is:
> [X] Stable - no major issues
> [ ] Beta - at least one significant issue -- tell us what it is
> [ ] Alpha - multiple significant issues -- tell us what they are

Mark

-
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] Tomcat 4.1.34 Stability

[Remy Maucherat]

Mark Thomas wrote:

All,

4.1.34-beta has been available for just over a month. Tomcat 4.1.34
fixes all open bugs against the 4.1.x branch and updates the libraries
to the latest versions. Please vote on its stability using the options
below.

I will also solicit feedback from the users list in case someone has
found a show stopper but hasn't reported it for whatever reason.

Apache Tomcat 4.1.34 is:
[X] Stable - no major issues
[ ] Beta - at least one significant issue -- tell us what it is
[ ] Alpha - multiple significant issues -- tell us what they are


I only did quick testing, though.

Rémy


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

DO NOT REPLY [Bug 40677] New: - PKCS11 keystore instead of JKS or PKCS12 keystore

[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=40677

   Summary: PKCS11 keystore instead of JKS or PKCS12 keystore
   Product: Tomcat 5
   Version: 5.5.17
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: trivial
  Priority: P5
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


The documentations says "Tomcat currently operates only on JKS or PKCS12 format
keystores". This is wrong!

I statically installed a Sun PKCS#11 provider and used the keystore on a
smartcard (Kobil mIdentity). I only had to change the "keystoreType" in the
server.xml file to "PKCS11" and it worked. 

Maybe you want to change the documentation.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Re: [VOTE] Tomcat 4.1.34 Stability

[Peter Rossbach]

Apache Tomcat 4.1.34 is:
[x ] Stable - no major issues


I found only a small issue at service.bat

Many thanks for that release
Peter


===

My Mail from 14.09.2006

s.
Hi Mark,

I have tested Tomcat 4.1.34 at windows with jdk 1.4.2_12.
The service.bat script don't add the %JAVA_HOME%/lib/tools.jar.

L80
set PR_CLASSPATH=%CATALINA_HOME%\bin\bootstrap.jar
--
set PR_CLASSPATH=%CATALINA_HOME%\bin\bootstrap.jar;%JAVA_HOME%\lib 
\tools.jar


Can we also change the link
L77
set PR_DESCRIPTION=Apache Tomcat Server - http://jakarta.apache.org/ 
tomcat

--
set PR_DESCRIPTION=Apache Tomcat Server - http://tomcat.apache.org

-

I have test the AJP connector successfully.

Many thanks to release 4.1.34
Peter
==

Am 04.10.2006 um 02:32 schrieb Mark Thomas:


All,

4.1.34-beta has been available for just over a month. Tomcat 4.1.34
fixes all open bugs against the 4.1.x branch and updates the libraries
to the latest versions. Please vote on its stability using the options
below.

I will also solicit feedback from the users list in case someone has
found a show stopper but hasn't reported it for whatever reason.

Apache Tomcat 4.1.34 is:
[ ] Stable - no major issues
[ ] Beta - at least one significant issue -- tell us what it is
[ ] Alpha - multiple significant issues -- tell us what they are

Many thanks,

Mark

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

Package renaming

[Remy Maucherat]

Hi,

I think Tomcat would be more robust if commons-logging was package 
renamed (this is the last commons- which is not package renamed at the 
moment, BTW), so I propose doing that.


It would mean integration with alternate loggers in Tomcat is more 
difficult (the wrapper would have to be package renamed too), but OTOH 
it would avoid classloading issues with the webapp. The implementation 
which could be used is the one from tomcat-lite (since it's small and 
robust).


It's a bit power/flexibility vs robustness, here.

Comments ?

Rémy

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

Re: Package renaming

[Yoav Shapira]

Hi,
Pure neutral zero on this one, so I guess I'm not being particularly
helpful.  On one hand I hate the renaming thing because it feels like
an ugly hack and it makes life more difficult for downstream
packagers.  On the other hand, we haven't had any DBCP-related
complaints (besides the one from the downstream repackager last month)
since we started repackaging it, which is nice.

Yoav

On 10/4/06, Remy Maucherat <[EMAIL PROTECTED]> wrote:

Hi,

I think Tomcat would be more robust if commons-logging was package
renamed (this is the last commons- which is not package renamed at the
moment, BTW), so I propose doing that.

It would mean integration with alternate loggers in Tomcat is more
difficult (the wrapper would have to be package renamed too), but OTOH
it would avoid classloading issues with the webapp. The implementation
which could be used is the one from tomcat-lite (since it's small and
robust).

It's a bit power/flexibility vs robustness, here.

Comments ?

Rémy

-
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: Package renaming

[Remy Maucherat]

Yoav Shapira wrote:

Hi,
Pure neutral zero on this one, so I guess I'm not being particularly
helpful.  On one hand I hate the renaming thing because it feels like
an ugly hack and it makes life more difficult for downstream
packagers.  On the other hand, we haven't had any DBCP-related
complaints (besides the one from the downstream repackager last month)
since we started repackaging it, which is nice.


At least, the technique has predictable results :/

Rémy

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

Re: Package renaming

[Peter Rossbach]

Hi!

At which tomcat release you want to change it?  6.0

That change can be break subclasses or components from other people,  
not nice.

Has you talk with Boris and future usage of his x4juli lib?

But I also see your arguments to do that. Hmm!

You want use the commons-logging 1.1 code base?

Regards
Peter

Am 04.10.2006 um 17:15 schrieb Remy Maucherat:


Hi,

I think Tomcat would be more robust if commons-logging was package  
renamed (this is the last commons- which is not package renamed at  
the moment, BTW), so I propose doing that.


It would mean integration with alternate loggers in Tomcat is more  
difficult (the wrapper would have to be package renamed too), but  
OTOH it would avoid classloading issues with the webapp. The  
implementation which could be used is the one from tomcat-lite  
(since it's small and robust).


It's a bit power/flexibility vs robustness, here.

Comments ?

Rémy

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

DO NOT REPLY [Bug 40679] New: - PermGen Space OutOfMemory Error after repeated Reload

[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=40679

   Summary: PermGen Space OutOfMemory Error after repeated Reload
   Product: Tomcat 5
   Version: 5.5.9
  Platform: PC
   URL: http://www.netbeans.org/issues/show_bug.cgi?id=86407
OS/Version: Windows 2000
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


Using Tomcat's Manager user interface I repeatedly
redployed (the button is labeled "Reload" in the Tomcat Manager UI) a simple web
application and I saw perm gen increase in size (by about 8K) each time.  When
the web application has more classes, the increase is more rapid.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 40679] - PermGen Space OutOfMemory Error after repeated Reload

[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=40679





--- Additional Comments From [EMAIL PROTECTED]  2006-10-04 09:25 ---
See http://www.netbeans.org/issues/show_bug.cgi?id=86407 for more details.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 39088] - StandardWrapper getRootCause() infinite loop

[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=39088





--- Additional Comments From [EMAIL PROTECTED]  2006-10-04 09:34 ---
Wouter,  unfortunately nothing ever gets fixed in Tomcat.  The people who can 
make the changes think there shit doesn't stink, and unless they find the bug 
and it affects them, it doesn't exist.  The patch for this would be like 1 
line of code, and the one Tim provided above (with the typical Tomcat 
developer sarcastic asshole mentality) is almost worse than the current code.  
I won't write a patch, and you shouldn't either.  Noone will incorporate one 
into the Tomcat codebase, ever, or let you put it in.  They will give excuses 
like, "if we fix it, it could break code that depends on it being broken".  
Good luck.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 40680] New: - SSL issue with X509 own signed certs but same in pkcs12 work

[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=40680

   Summary: SSL issue with X509 own signed certs but same in pkcs12
work
   Product: Tomcat 5
   Version: 5.5.17
  Platform: Other
OS/Version: Windows XP
Status: NEW
  Severity: major
  Priority: P2
 Component: Unknown
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


When using self signed certificates, I get no problem to get SSL connections
with Tomcat.

Then I tried using the certificate I already used in Apache (and that worked
well). This certificate has been signed by my own CA, which I created with CA.pl
from OpenSSL. This certificate is server.cert and is PEM encrypted.
Here is what I did : 
1) Make a X509 valid certificate :
openssl x509 -in server.cert -out serverx509.pem

2) import the certificate in a keystore :
keytool -import -keystore c:\ssl\.keystore -alias tomcat -file serverx509.pem
(password is "changeit" as expected by Tomcat)

The import is OK, I get a correct .keystore file which I can read with :
keytool -list -keystore c:\ssl\.keystore

4) Configure Tomcat in server.xml :



5) Launch Tomcat :
Tomcat launches but catalina.xxx.log tells me :
4 oct. 2006 17:11:41 org.apache.catalina.core.AprLifecycleListener 
lifecycleEvent
INFO: The Apache Tomcat Native library which allows optimal performance in
production environments was not found on the java.library.path: C:\Program
Files\Apache Software Foundation\Tomcat
5.5\bin;.;C:\WINDOWS\System32;C:\WINDOWS;C:\Perl\bin\;C:\Program Files\Windows
Resource
Kits\Tools\;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program
Files\ATI Technologies\ATI Control Panel;C:\Program Files\Fichiers
communs\GTK\2.0\bin;C:\informix\bin;c:\OpenSSL\bin;C:\Program
Files\Java\jre1.5.0_09\bin
4 oct. 2006 17:11:41 org.apache.coyote.http11.Http11BaseProtocol init
INFO: Initialisation de Coyote HTTP/1.1 sur http-8081
4 oct. 2006 17:11:42 org.apache.coyote.http11.Http11BaseProtocol init
INFO: Initialisation de Coyote HTTP/1.1 sur http-8443
4 oct. 2006 17:11:42 org.apache.catalina.startup.Catalina load
INFO: Initialization processed in 1472 ms
4 oct. 2006 17:11:42 org.apache.catalina.core.StandardService start
INFO: Démarrage du service Catalina
4 oct. 2006 17:11:42 org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/5.5.17
4 oct. 2006 17:11:42 org.apache.catalina.core.StandardHost start
INFO: XML validation disabled
4 oct. 2006 17:11:44 org.apache.catalina.startup.HostConfig deployWAR
INFO: Déploiement de l'archive standard-examples.war de l'application web
4 oct. 2006 17:11:45 org.apache.catalina.startup.HostConfig deployWAR
INFO: Déploiement de l'archive PharmaJ.war de l'application web
4 oct. 2006 17:11:46 org.apache.coyote.http11.Http11BaseProtocol start
INFO: Démarrage de Coyote HTTP/1.1 sur http-8081
4 oct. 2006 17:11:46 org.apache.coyote.http11.Http11BaseProtocol start
INFO: Démarrage de Coyote HTTP/1.1 sur http-8443
4 oct. 2006 17:11:46 org.apache.tomcat.util.net.PoolTcpEndpoint acceptSocket
GRAVE: Le point de contact [SSL:
ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=8443]] a ignoré l'exception:
java.net.SocketException: SSL handshake errorjavax.net.ssl.SSLException: No
available certificate or key corresponds to the SSL cipher suites which are 
enabled.
java.net.SocketException: SSL handshake errorjavax.net.ssl.SSLException: No
available certificate or key corresponds to the SSL cipher suites which are 
enabled.
at
org.apache.tomcat.util.net.jsse.JSSESocketFactory.acceptSocket(JSSESocketFactory.java:113)
at
org.apache.tomcat.util.net.PoolTcpEndpoint.acceptSocket(PoolTcpEndpoint.java:407)
at
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:70)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Unknown Source)
4 oct. 2006 17:11:46 org.apache.tomcat.util.net.PoolTcpEndpoint acceptSocket
ATTENTION: Réinitialisation du ServerSocket
[...]

And I can't get a ssl connection of course


I've been working on it hard for several days and then found a post on a mail
list, which suggested to use pkcs12 keystore instead.
So, here is what I did :
6) Create a pkcs12 from the already existing server.cert (the same file as used
above !) :
openssl pkcs12 -export -in server.cert -out keystore.p12 -inkey server.key -name
"Certificat Serveur Tomcat"
move keystore.p12 c:\ssl\

7) Configure Tomcat to use a pkcs12 keystore :



8) Launch Tomcat :
It works !
Here is the catalina.xxx.log :
4 oct. 2006 17:30:05 org.apache.catalin

Re: Package renaming

[William L. Thomson Jr.]

On Wed, 2006-10-04 at 11:21 -0400, Yoav Shapira wrote:
> Hi,
> Pure neutral zero on this one, so I guess I'm not being particularly
> helpful.  On one hand I hate the renaming thing because it feels like
> an ugly hack and it makes life more difficult for downstream
> packagers.

Please, please, please, keep downstream packagers in mind when making
decisions like this.

>   On the other hand, we haven't had any DBCP-related
> complaints (besides the one from the downstream repackager last month)

I can't say how big of a problem building that jar is at the present
time on Gentoo given our build systems. Tomcat is one of the few java
apps that we are unable to build all aspects of. Due to repackage
sources, not binaries, from other projects into the final binary result.

I have no foreseeable solution to building that jar on Gentoo at this
time. I have discussed it extensively with others, and we are likely to
have to do some package specific hacks or etc to build that jar. In the
mean time, those needing that jar are having to fetch it from the a
binary release.

I would think re-packaging sources from other Java apps into other
binaries, jars etc would be far from ideal. However if it was
re-packaging, overloading, or etc binaries, that's another story. Much
less of an issue.

Otherwise I would suggest Tomcat package any sources used during
compilation. Even if they are sources from another project. Instead of
pulling them down via ant at build time if they are not present.

Thanks

Also FYI, we had a 0 day release of Tomcat 5.5.20 on Gentoo :)
Along with a 0 day release of mod_jk 1.2.19 as well. Both are still are
keyworded experimental/unstable. In 30 or so days will be stable barring
any major bug reports.

-- 
William L. Thomson Jr.
Gentoo/Java


signature.asc
Description: This is a digitally signed message part

DO NOT REPLY [Bug 38351] - context.xml not used when new host created.

[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=38351


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2006-10-04 10:50 ---
It works alot better if you don't set deployXML to false in the command to the
Host Manager.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Re: Package renaming

[Filip Hanik - Dev Lists]

I'm all for it, I don't like it, but it prevents version issues when 
users slap add in their own versions, hence it makes tomcat itself more 
manageable.


Filip


Remy Maucherat wrote:

Hi,

I think Tomcat would be more robust if commons-logging was package 
renamed (this is the last commons- which is not package renamed at the 
moment, BTW), so I propose doing that.


It would mean integration with alternate loggers in Tomcat is more 
difficult (the wrapper would have to be package renamed too), but OTOH 
it would avoid classloading issues with the webapp. The implementation 
which could be used is the one from tomcat-lite (since it's small and 
robust).


It's a bit power/flexibility vs robustness, here.

Comments ?

Rémy

-
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 40572] - Performance problem with org.apache.catalina.loader and JAXP, JSP

[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=40572





--- Additional Comments From [EMAIL PROTECTED]  2006-10-04 11:58 ---
Mostly I agree but I believe you could consider a less extensive .toString()
method and a more extensive debugString() method, since programmers in other
systems may not see merely mentioning the classloader as an expensive operation
(the perils of operator overloading).  On a secondary note, invocation
benchmarks will not take into account distributed GC time.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Re: Package renaming

[Remy Maucherat]

Peter Rossbach wrote:

Hi!

At which tomcat release you want to change it?  6.0


Of course.


You want use the commons-logging 1.1 code base?


No, probably use what is in the sandbox to start with.

Rémy

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

Re: Package renaming

[Remy Maucherat]

William L. Thomson Jr. wrote:

I have no foreseeable solution to building that jar on Gentoo at this
time. I have discussed it extensively with others, and we are likely to
have to do some package specific hacks or etc to build that jar. In the
mean time, those needing that jar are having to fetch it from the a
binary release.


Ok, but you don't really have to care that much about that JAR: Tomcat 
is still perfectly usable using the regular commons-dbcp, etc.


It's not the same situation here, so you won't run into any problem. An 
implementation of commons-logging (I thought the one Costin did in 
tomcat-lite could be reasonable to start with) would be included in the 
Tomcat source and built along with the rest.


Rémy

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

Re: Package renaming

[William L. Thomson Jr.]

On Wed, 2006-10-04 at 21:52 +0200, Remy Maucherat wrote:
> William L. Thomson Jr. wrote:
> > I have no foreseeable solution to building that jar on Gentoo at this
> > time. I have discussed it extensively with others, and we are likely to
> > have to do some package specific hacks or etc to build that jar. In the
> > mean time, those needing that jar are having to fetch it from the a
> > binary release.
> 
> Ok, but you don't really have to care that much about that JAR: Tomcat 
> is still perfectly usable using the regular commons-dbcp, etc.

Sure, and most JDBC drivers have their own factories as well. It's just
users freak at first and is one of the little annoying pains. I have
never been effected by it missing, but many that don't specify a factory
at all. Tend to need that jar, since it's the default factory used when
non are specified.

Really only reasons I care about the jar is
1. To be like upstream releases (for the most part)
2. So users don't get cnfe or etc when the jar is mia

> It's not the same situation here, so you won't run into any problem. An 
> implementation of commons-logging (I thought the one Costin did in 
> tomcat-lite could be reasonable to start with) would be included in the 
> Tomcat source and built along with the rest.

Terrific :)

I have no problem with any sources bundled with Tomcat. Nor Tomcat's
deps on binaries the sources do not ship with. It's just dependencies on
sources Tomcat does not ship with is my pain/gripe atm.

I appreciate you all being receptive to this coming from downstream :)

-- 
William L. Thomson Jr.
Gentoo/Java


signature.asc
Description: This is a digitally signed message part

svn commit: r453023 - /tomcat/tc6.0.x/trunk/java/org/apache/jasper/compiler/Generator.java

[remm]

Author: remm
Date: Wed Oct  4 14:02:16 2006
New Revision: 453023

URL: http://svn.apache.org/viewvc?view=rev&rev=453023
Log:
- Fix non deferred attributes evaluation.
- Headache inducing patch submitted by Stan Silvert.

Modified:
tomcat/tc6.0.x/trunk/java/org/apache/jasper/compiler/Generator.java

Modified: tomcat/tc6.0.x/trunk/java/org/apache/jasper/compiler/Generator.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/jasper/compiler/Generator.java?view=diff&rev=453023&r1=453022&r2=453023
==
--- tomcat/tc6.0.x/trunk/java/org/apache/jasper/compiler/Generator.java 
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/jasper/compiler/Generator.java Wed Oct 
 4 14:02:16 2006
@@ -2817,6 +2817,24 @@
 sb.append(',');
 sb.append(returnType);
 sb.append("))");
+// should the expression be evaluated before passing to
+// the setter?
+boolean evaluate = false;
+if (tai.canBeRequestTime()) {
+evaluate = true; // JSP.2.3.2
+}
+if (attr.isDeferredInput()) {
+evaluate = false; // JSP.2.3.3
+}
+if (attr.isDeferredInput() && tai.canBeRequestTime()) {
+evaluate = !attrValue.contains("#{"); // JSP.2.3.5
+}
+if (evaluate) {
+sb.append(".getValue(");
+sb.append(getJspContextVar());
+sb.append(".getELContext()");
+sb.append(")");
+} 
 attrValue = sb.toString();
 } else if (attr.isDeferredMethodInput()
 || MethodExpression.class.getName().equals(type)) {



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