[EMAIL PROTECTED] typed the following on 02:07 PM 2/6/2001 -0800
( +2 if he also ports them to tomcat 3.3 or makes them independent of
the container architecture - i.e. general purpose utils for
serialization/deserialization with a simple adapter for each server :-)
Sure, the 3.3 code could
Hi,
The Makefile in jakarta-tomcat-4.0/connectors are broken. I have fixed
them. Find enclosed the patch.
Cheers
Jean-frederic
? Makedefs
? patch.txt
? apache-1.3/.libs
Index: Makefile
===
RCS file:
Did you succeed using the web_app connector ?
I still have the same problem with cookies...
La prise de conscience de votre propre ignorance est un grand pas vers la
connaissance.
-- Benjamin Disraeli
-Original Message-
From: jean-frederic clere [mailto:[EMAIL PROTECTED]]
Sent:
GOMEZ Henri wrote:
Did you succeed using the web_app connector ?
Not yet!
I still have the same problem with cookies...
La prise de conscience de votre propre ignorance est un grand pas vers la
connaissance.
-- Benjamin Disraeli
-Original Message-
From: jean-frederic
The new jasper makes it very easy to find and view
the java source for
a translated jsp page, it is located in
work/somehost/someapp/some/context/path/MyJSP.java.
Does it not seem logical to assign a package to the
MyJSP class based on all or part of the above path?
Hi,
In Turbine I wanted to provide an easy way to give
all classes in a webapp easy access to the real
path to the webapp: someone on the Turbine list
mentioned that ServletContext.getRealPath(path)
is not required to be implemented. If this is
the case what is the best way to provide access
to
Placing all generated servlet classes into the same package only works if
the loader cooperates. If the container does not use a separate, special,
classloader for each page, it will not be able to distinguish the different
instances of MyJSP.class, or in my case of index.class.
That implies
Jason van Zyl wrote:
Hi,
In Turbine I wanted to provide an easy way to give
all classes in a webapp easy access to the real
path to the webapp: someone on the Turbine list
mentioned that ServletContext.getRealPath(path)
is not required to be implemented. If this is
the case what is the
Tomcat-Apache is my choice to implement JSP.
i wish to u JDBC-ODBC bridge to link database with JSP pages.
i were told that JDK 1.3 standard edition does not support JDBC, therefore,
i have installed "j2sdkee-1_2_1-win" -- JSDK enterprise edition. However,
the below problem occurs
'
on 2/7/01 10:24 AM, "BOON PING LIM" [EMAIL PROTECTED] wrote:
Tomcat-Apache is my choice to implement JSP.
i wish to u JDBC-ODBC bridge to link database with JSP pages.
i were told that JDK 1.3 standard edition does not support JDBC, therefore,
i have installed "j2sdkee-1_2_1-win" -- JSDK
Steve Downey wrote:
Placing all generated servlet classes into the same package only works if
the loader cooperates. If the container does not use a separate, special,
classloader for each page, it will not be able to distinguish the different
instances of MyJSP.class, or in my case of
Hi,
I'm not sure what I'm missing here, but I'm running
into a strange bit of behavior in Tomcat 3.2.1.
I've got a jsp that uses classes in a jar file that is
placed in the WEB-INF/lib folder like so:
webapps/demo/simple.jsp
webapps/demo/WEB-INF/lib/mylib.jar
Early on one of the classes
Mel Martinez wrote:
Hi,
I'm not sure what I'm missing here, but I'm running
into a strange bit of behavior in Tomcat 3.2.1.
I've got a jsp that uses classes in a jar file that is
placed in the WEB-INF/lib folder like so:
webapps/demo/simple.jsp
webapps/demo/WEB-INF/lib/mylib.jar
marcsaeg01/02/07 15:24:57
Added: .Tag: tomcat_32 RELEASE-PLAN-3.2.2
Log:
First draft of the proposed release plan for Tomcat 3.2.2
Revision ChangesPath
No revision
No revision
1.1.2.1 +67 -0
We have collected quite a few good bug fixes on the tomcat_32 branch since
the release of Tomcat 3.2.1. I propose that we make a public release of the
tomcat_32 branch as Tomcat 3.2.2. A proposed release plan can be found at
keith 01/02/07 15:49:45
Modified:src/share/org/apache/tomcat/modules/server Ajp13.java
Log:
Add the WebDAV ACL method.
Revision ChangesPath
1.12 +2 -1
jakarta-tomcat/src/share/org/apache/tomcat/modules/server/Ajp13.java
Index: Ajp13.java
keith 01/02/07 15:51:07
Modified:src/doc AJPv13.html
Log:
Document the added ACL method.
Revision ChangesPath
1.3 +1 -0 jakarta-tomcat/src/doc/AJPv13.html
Index: AJPv13.html
===
RCS
on 2/7/01 3:34 PM, "Marc Saegesser" [EMAIL PROTECTED] wrote:
Please review and comment on the proposed release plan. I will call release
plan vote in the near future.
+0 if and only if (ie: not -1) the following is modified to state:
"Any bug introduced after Tomcat 3.2.1 MUST be fixed."
keith 01/02/07 15:47:15
Modified:src/native/mod_jk/common jk_ajp13.c
Log:
Add the ACL method to ajpv13
(see http://www.ietf.org/internet-drafts/draft-ietf-webdav-acl-04.txt)
Revision ChangesPath
1.5 +7 -3
marcsaeg01/02/07 17:05:35
Modified:.Tag: tomcat_32 RELEASE-PLAN-3.2.2
Log:
Updated release criteria to include Bugzilla resolution requirements.
Revision ChangesPath
No revision
No revision
1.1.2.2 +8 -6
I'm trying to integrate Tomcat 3.2.1 with my application, and have modified
the implementation of SSLSocketFactory to use my keystore and trust manager.
I have a certificate in my keystore, but it has a different alias (not
tomcat) and I cannot change the alias.
Where in the tomcat source code
How about the following:
Any bug introduced by a code change since Tomcat 3.2.1 was released MUST
be fixed. If it worked in 3.2.1 it will work in 3.2.2.
All Bugzilla items opened against "Tocmat 3" must be marked as RESOLVED.
Those items that are not going to be fixed in Tomcat 3.2.2 will be
craigmcc01/02/07 17:58:07
Modified:catalina/src/share/org/apache/catalina/loader
StandardClassLoader.java
Log:
Add some additional debugging instrumentation to assist in locating the
"package sealing violation" exception problem.
Revision Changes
on 2/7/01 6:05 PM, Craig R. McClanahan at [EMAIL PROTECTED]
wrote:
For those interested in the gory details, the problem is in
StandardClassLoader.findClass(), which delegates to the parent class
loader prior to checking the local repositories (I'm not sure this is
really correct behavior --
Why you cannot use only one setter "public setIndex (String index)" and then inside
check if the
string is convertable to integer or not? This way your index can represent a number or
"all".
"Craig R. McClanahan" wrote:
Alex Tang wrote:
Thanks for the quick reply Craig.
A followup
Maya Muchnik wrote:
Why you cannot use only one setter "public setIndex (String index)" and then inside
check if the
string is convertable to integer or not? This way your index can represent a number
or "all".
In Tocmat 3.x, your suggestion works if the tag looks like:
Alex Tang wrote:
Thanks for the quick reply Craig.
A followup question. In tomcat 3.1, I was able to do
public setIndex ( Object o )
If this is legal, I can do my own internal checking to see if the object "o" is a
String or an
int. However in Tomcat 4.0, I get an error when I
Alex,
Until the expert group rules on this, one workaround (that will always work)
is to simply do the following (assuming a property of type Object):
instead of:
mytags:foo bar="abc"/
use:
mytags:foo bar='%="abc"%'/
Another way is to define a PropertyEditor associated
28 matches
Mail list logo
