Hi Alex,
I'll check this - but what I said is the syntax used in 3.2 should still
work ( i.e. RequestInterceptor name=class.name ... / ). It is still
used ( more as a sample ) for the connectors.
That doesn't mean the same configuration will work - some of the modules
were rewritten (
Hi Mike,
Strange... I'll look into it, I was planning to review once again the
reloading code ( to detect changes in modules and reload them or the
context using them ), I'll try to reproduce and fix this one too.
Costin
On Thu, 28 Jun 2001, Mike Anderson wrote:
I think I've found a problem
On Tue, 26 Jun 2001, Alex Fernández wrote:
tomcat -config server.xml
passing a new server.xml file. Can I do something similar in Tomcat 3.3?
I cannot find a similar option in the docs; I believe it's ignoring it.
Of course. Everything that works in 3.2 should also work ( better ) in
On Tue, 26 Jun 2001, Jonathan Reichhold wrote:
Jakarta-tomcat-connectors appears to be available only through CVS. The src can't
be obtained from http://jakarta.apache.org/ I
was wondering about the connectors myself until I went to the CVS repository
directly.
Would it not make sense
On Mon, 25 Jun 2001, Thom Park wrote:
Hi
Does anyone have an E.T.A. on when the connectors will return to the nightly
builds
and/or when they will return to being included in the nighty source drops?
Which connectors :-) ?
If you are talking about the native mod_jk/mod_webapp - I didn't
Not easy - you may need a modified mod_jk for that.
The handler name is jakarta-servlet, but the current module does some
work in translate(), to determine which protocol and tomcat instance to
use. The change is probably easy, configure/use a default protocol and
instance and use it.
The
On Sun, 24 Jun 2001, Justin Erenkrantz wrote:
That just leads to formatting problems because people don't understand
that. If you must have tabs, they should be the same as the indention
level, not some factor of the indention level. This doesn't have to be
complicated. One tab == one
On Mon, 25 Jun 2001, Jun Inamori wrote:
IE (at least IE 5.5 on Windows95) encodes the request URL by the way of:
one Japanese character -- %XX%XX%XX
And this results in the corrupted URL String.
I'm not sure, but I remenber that Costin pointed this is the bad
behavior of IE.
No, that's
On Sun, 24 Jun 2001, kevin seguin wrote:
hey costin, one of the things i've been planning on doing is changing
o.a.ajp.AjpRequest to make use of o.a.coyote.Request. basically, wrap
Request in AjpRequest. does this conflict with your plans?
Yes, a bit, as I'm going to wrap AjpRequest in a
On Sun, 24 Jun 2001, kevin seguin wrote:
i've been thinking about this, and, well, isn't this BaseRequest you're
talking about kind of what org.apache.coyote.Request is? does it make
sense to have two of these kinds of objects hanging around? is
o.a.c.Request roughly equivalent to
Ok, I've got the first request served via Ajp14. There are probably few
details to resolve ( like the fact that the connection is closed after
authentication - I'm not sure why ).
I can now start playing with some of the fun callbacks I want ( and maybe
abstract a bit the marshling and
Hi David,
Thanks for this report, I'm impressed on your deep understanding of the
subject. Class loading is one of the most difficult areas, and until Nacho
implemented most of the new loader scheme we had lots of problems. ( that
happened few months ago ).
Here's the list of things that I
On Sat, 23 Jun 2001, Craig R. McClanahan wrote:
A) the hierarchy should go:
SystemCL
| -- LAYER 1
lib/common CL
/ \ -- LAYER 2
lib/container lib/apps CL
|--
On Sat, 23 Jun 2001, Craig R. McClanahan wrote:
Servlet 2.3 PFD2, defines sensitive for the purposes of conformance: J2SE
and servlet API classes.
Well, that's not very good if you have a sensitive driver ( a native
JDBC for friver for example ) or similar. But if this is the definition -
Ok, first change.
Would it be ok with you if I just drop Ajp14Packet in jk, and use the
plain ByteChunk, plus a Ajp14Marshall to implement the marshaling on
top of ByteChunk ?
The idea is that ( someday - soon I hope ) ByteChunk will be able ( via a
Liaison or the o.a.t.util.compat ) to
On Sat, 23 Jun 2001, Andy Armstrong wrote:
Here we go... ;-)
I like tabs set to four spaces, tabs in source rather than spaces and
opening braces on a new line. How evil does that make me?
Not necesarily evil, I also like the week with 3 days ( 1 for work, 2 for
weekend ), tabs in source,
On Fri, 22 Jun 2001, Craig R. McClanahan wrote:
* There are existing Tomcat committers who adamantly swear
by using tab characters (who will speak up if they feel
like it :-) despite the community's repeatedly expressed
convention for spaces.
I'm one :-)
I'm not sure about
Ok, after a lot of gdb-ing and strugling with the ./configure and apr
I got apache2 working.
To save other's some time:
If you see SIGSEGV just after you start ( you can use
httpd -D ONE_PROCESS, that replaces the old -X and env ), one place to
look is srclib/apr/shmem/unix/mm.
There is a
Hi Larry,
Those options are already implemented - it's just a matter of turning them
on or off, and I wasn't targeting M4.
There are few issues building in JDK1.1, but I think we are ok with
building M4 this night ( with the final tommorow ).
Regarding jasper34, it passes all watchdog/sanity
On Thu, 21 Jun 2001, Michael Jennings wrote:
That's true. The point I was trying to make is that there is nothing to
stop an end-user from bookmarking a login page or typing it in
directly, even if you have no linkages to the login page in your
user interface.
It's kinda hard
On Thu, 21 Jun 2001, Michael Jennings wrote:
Okay,
I was being stupid. I understand now, with form-based authentication when
you
request /mywebapp/private/somefile.jsp what you get back should just be
generated from the login page, then when you submit your credentials,
it returns
On Thu, 21 Jun 2001, Craig R. McClanahan wrote:
If the login page would be displayed all the a href= / or img in the
login page will be treated by the browser as relative to
/mywebapp/private, while the login page can be somewhere else.
The form login page should use server-relative
What I remember - it was there, and I never understood very well why :-)
That's one of the reasons I put a lot of time into OutputBuffer and
refactoring the output system.
My best guess was that it is related with higher level code ( Writer,
JspWriter most likely ) that needs to empty it's
On Tue, 19 Jun 2001, Aaron Bannert wrote:
Connectors
--
* jk: The native and java parts of the ajp12/ajp13 [is this correct?]
connector. Both Tomcat 4.0 and Tomcat 3.3 are supported.
* webapp: The native and java parts of the ajp14 connector, now known
as mod_webapp and
+1.
Costin
On Wed, 20 Jun 2001, Ignacio J. Ortega wrote:
+1
Saludos ,
Ignacio J. Ortega
-Mensaje original-
De: Larry Isaacs [mailto:[EMAIL PROTECTED]]
Enviado el: martes 19 de junio de 2001 23:49
Para: '[EMAIL PROTECTED]'
Asunto: Some clean up of the jakarta-tomcat
Can you send a URI that shows the problem ( including the special chars )?
Are the chars encoded ( %something ) or not ? This is an important one,
thanks for the report.
Costin
On Mon, 18 Jun 2001, Angel Aray wrote:
I am having problems with tomcat handlings of special characters.
I found the problem, I'm working on a fix.
It happens only when you send the high bytes ( well, the URL is supposed
to have only ASCII ), and the query decoding defaults right now to UTF8.
The simple fix is to change the default to 8859_1, as required by spec,
but the right fix is to pass the
Hi Nacho,
I was thinking of the dependencies, maybe it would be good to reverse it.
o.a.t.u.depend package is used to record dependencies and handle reloading
( or anything related with deps ).
o.a.t.u.compat is used to allow the use of version-depenent JVM functions,
and provide equivalent (
+1, I think most things will be easier now in jasper34 space, JspServlet
was one of the scariest things but it's starting to look better.
BTW, did anyone tested the per-session encoding stuff ? Can we keep it on
by default ( given that all known browsers will post in the same encoding
the form
On Sat, 16 Jun 2001, Casey Lucas wrote:
ok. just let me know when you think it's appropriate to
start adding some tag optimizations.
I assume the changes will be local to 2-3 generators and runtime. We
should be able to have them in parallel, it would generate some conflicts
in cvs but we
Hi Carlos,
Interesting :-) I thing Sam Ruby might help you ( I don't know if he's
still on this list ).
Costin
On Sat, 16 Jun 2001, Carlos Gaston Alvarez wrote:
Hi there,
Steve and me have the intention of implementing Jython as a language
for jsp. Jython compiles to java so it
Hi Nacho,
Can you try again with the latest CVS and send a trace ( I did a number of
changes and the lines are different now ).
Are you using jikes ?
Costin
On Sat, 16 Jun 2001, Casey Lucas wrote:
Jasper already understands what things like jsp:useBean do, and it
generates specialized code to implement the required functionality (rather
than treating it like a custom tag).
right. i thought he might be refering to custom tags. that's where
On Sun, 17 Jun 2001, Ignacio J. Ortega wrote:
Hola Costin:
Can you try again with the latest CVS and send a trace ( I
did a number of
changes and the lines are different now ).
Now works. Thanks.
But I've got 2 Fails ( This is failing with Jasper33 too )
FAIL ( This URL
On Fri, 15 Jun 2001, Pier P. Fumagalli wrote:
Haydn Haines - Sun UK - Partner Support at [EMAIL PROTECTED] wrote:
Hi All,
The tomcat 3.2.2 README file states that jdk 1.1 or later AND JSSE
1.0.2 or later are required...
However, the JSSE 1.0.2 install.html states that JSSE 1.0.2
Hi ( Larry ),
I'll review the new bugs over the weekend, and I hope we can get a new
milestone out for next week.
Do you think it would be possible to enable jasper34 in the next
milestone? It would help me a lot in the refactoring process, the code is
stable ( the generated code is almost
On Fri, 15 Jun 2001, Morrison, John wrote:
Would/could this be implemented as a web context with (possibly) some
'administration' flag set in it's context that way, if you didn't want to
have a GUI (security?) you could just remove the context?
This is how it is implemented today in tomcat
On Fri, 15 Jun 2001, Casey Lucas wrote:
Costin,
sounds good.
btw, when do you think the generator code in 34 will settle down
a little?
Soon :-)
There is only one more change in the generator layout - switching to
a visitor pattern, with the tree representation of the page separated
On Fri, 15 Jun 2001, Larry Isaacs wrote:
Next week sounds good for a Milestone 4. I'll try to propose
a new RELEASE-PLAN-3.3 this weekend.
What is involved in enabling jasper34? Assuming that is
fairly simple I don't have a problem enabling jasper34.
We will need to document how to
Thanks for the report - if you can think of a patch we can use it for
3.2.3. The reloading system has been almost completely rewritten for 3.3,
with far fewer accesses to the file system.
Have you tried with a different VM ? ( I don't think we can avoid
getCanonicalPath, is a very useful call
On Thu, 14 Jun 2001, Robert Slifka wrote:
Rather than continue to bludgeon people with documentation they refuse to
read (as one poster writes, ...hence i would like to get your ideas rather
than just reading through the docs) is there something else that can be
done?
Or maybe a
+0 - most of my time will be split between jasper34 and tomcat33 ( and a
bit j-t-c, after jasper34 stabilize a bit ).
Costin
On Thu, 14 Jun 2001, Marc Saegesser wrote:
Now that Tomcat 3.2.2 is out it's time to starting thinking about 3.2.3. My
thoughts are to have a release for 3.2.3 in
Hi Remy,
I looked at coyote, and it looks good ( the Request and Response are
simplified and have no deps on a higher layer ).
Few issues:
- Note - the user should be able to store any object as a note, there is
no reason to require recycle on it ( if you want you could turn it into
Recyclable
It would be very good at this stage to go back 1 1/2 years in tomcat
archives and re-read the admin thread. It was a huge discussion, with
many ideas - but nothing happened.
As usual, my opinion is that you should start with a prototype and/or
existing code - and figure out what is the best
On Mon, 11 Jun 2001, Pier P. Fumagalli wrote:
And, if Costin gives out permission (he's root on those), we all should be
able also to access:
Solaris 7 / SPARC
- Running on a Sun Ultra-1 (UltraSparc/133) tokyo.javasoft.com
Linux 2.2.15 / SPARC
- Running on a Sun Ultra-1
On Mon, 11 Jun 2001, Steve Downey wrote:
On a production site it isn't a big factor - there are not too many
reloads.
Depends. I've done some content publishing work where JSPs are replaced
quite often while the engine is running. Of course, there are other ways of
accomplishing the
On Mon, 11 Jun 2001, JULIEN,TIMOTHY (HP-NewJersey,ex2) wrote:
Does jasper have an architecture goal to run in other Servlet Containers?
I ask because I am working on a Servlet/JSP Container, and the JSP portion
(a Servlet) has been kept separate for this exact reason. We would like our
JSP
My guess: you are starting tomcat from command line, not via invocation.
( so the JNI init method is not called ).
I'll try to add some extra checks and error messages in 3.3 ( for
graceful failure )
Costin
On Fri, 8 Jun 2001, Jonathan Harding wrote:
I am trying to setup tomcat-3.2.1 for
Hi,
Next step on line mapping is finding the JSP line that caused the
compiler error. For that we need to parse the compile error. Does anyone
know any existing code or some magic to get to a consistent format ?
Costin
Another issue:
At this moment we have 4 different manglers ( == converters between
jsp files and valid class names ):
- original ( uses a nice .class file hack to do versioning )
- jspc ( similar with original, but without versioning - AFAIK)
- jasper33 ( versioning, simpler names without
On Sun, 10 Jun 2001, Glenn Nielsen wrote:
Another advantage of jasper40 using a URLClassLoader for each individual
JSP page is that you don't accumulate outdated classes in the classloader
that eat up JVM memory when a JSP is recompiled. I haven't looked at
jasper33, so please let me know
Hi,
The current scheme ( used by some IDEs ) is to generate a comment in
the source code. This could be used by parsing the java file and
constructing a map.
I would like to change that to generate a real map that could be
used programmatically by the error reporting code ( and simplify the
On Sat, 9 Jun 2001, Craig R. McClanahan wrote:
I would like to change that to generate a real map that could be
used programmatically by the error reporting code ( and simplify the work
for debuggers ).
I'm not sure what would be the best structure for that.
There's a JSR (45)
Hi,
Unless someone has reasons not to, I will start changing the build
process to use the buffers and low-level objects in j-t-c. Over
the weekend I'll try to finish the move of all connector code
into j-t-c, where it belongs.
I would also try to add jasper34 ( as originally discussed ). It
On the Java Side I've started a quick patch on TC 3.3
Ajp13.java Ajp13Interceptor. I'll wait for TC 3.3
java code import to commit the java code for Ajp14 :)
Henri,
I'll try to do the commit over the weekend, after Java one.
I would like to start building the connector and buffers
Just to let you know - and keep a record of the attempt.
I did a small experiment, making all objects in tomcat Serializable
( a bit of perl ) and saving the state just before engineStart()
( when all the state is stable ).
Then at startup, detect if tomcat.ser is available and load it.
I
Just FYI, I don't think this is a good idea for general
tomcat authentication.
One reason is that credentials are not allways a simple string - you can
have complex authentication schemes where you require certain schemes
based on the IP address, etc.
GetUserRoles might not work for paranoid
On Tue, 5 Jun 2001, GOMEZ Henri wrote:
That was asked many time before but .
What about creating a sub project jakarta-tomcat-realms
What about jakarta-tomcat-modules ?
Connector is a big enough thing, same for jasper, but we shouldn't create
a repository for each type of module
What about using jaxp-1.1 ? You can now build the whole thing from
xml-commons, xml-crimson and xml-xalan.
Jaxp1.0 is quite old, we should upgrade ( many bugs were fixed ).
I personally prefer using crimson ( but I can live with xerces1 ) - code
size is the one reason ( I also worked much
Hi,
I'm going to do a number of commits on jasper34 - some will be large and I
want to give a summary to make it easier to track the changes.
Basically it's a 'simple' refactoring, the code is working almost the same
as before ( we're still passing all the tests we did, no important bug
is
On Sun, 27 May 2001, Jon Stevens wrote:
on 5/26/01 10:18 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
+{
+return oldCookieFormat.format( d );
}
I thought we weren't using tab's in the files anymore...
We are using tabs AFAIK ( or at least I am using tabs and I don't
On Sun, 27 May 2001, Michael Jennings wrote:
Hi!
I've made a modification to the ApacheConfig module to enable the
mod_jk.conf-auto to include directives to enable form-based authentication.
Can someone with commit privilege commit this change?
Done, thanks.
Costin
Here's the cvs
On Sun, 27 May 2001, Jon Stevens wrote:
on 5/27/01 4:01 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
We are using tabs AFAIK ( or at least I am using tabs and I don't
remember any vote or official rule that says this is not allowed ).
Costin
On Sun, 27 May 2001, Jon Stevens wrote:
on 5/27/01 5:04 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
http://jakarta.apache.org/site/source.html
Costin
Costin, you are being stupid (again).
However, some projects may decide to override these defaults and use their
own
On Sun, 27 May 2001, Jon Stevens wrote:
on 5/27/01 5:25 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Jon, try to write more code and less mail.
Once again, you completely miss the point Costin.
I guess you completely miss the point - calling people stupid and behaving
the way you
On Sun, 27 May 2001, kevin seguin wrote:
Regarding the connector - sorry I didn't had more time to spend on it, but
I'll be able to help more after I'll be back. I plan to do a
re-implementation of the java side of Ajp13/14, and also to do some
optimizations on the JNI side, and I'll
Hi Chris,
Can you reproduce this in normal JSP ( without oracle ) ? Can you send me
a small webapp where I can reproduce it ? Does it happens in 3.3 too ?
I am trying to solve (most) I18N bugs and problems for 3.3, it's very
tricky but can be done :-)
Costin
On Fri, 25 May 2001, Chris
On Sun, 27 May 2001, Jon Stevens wrote:
on 5/27/01 5:54 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
It's a matter of principle here - the fact that some mail clients or
editors chose to ignore standards and common practices doesn't mean the
standard itself is bad and shouldn't be
Hi,
I finished the initial commit, and ( a bit surprising ) it worked from the
first attempt... Not bad.
To try it out:
- get jakarta-tomcat
- build it
- get jakarta-tomcat-jasper
- build it with ant install
That will copy the jasper jars and fix the tomcat config ( replacing the
module class
On Sun, 27 May 2001, kevin seguin wrote:
The buffers do belong to jakarta-tomcat-connectors/util, and in a perfect
world we wouldn't have them duplicated - 3.3 should only use what's in
connectors.
I wouldn't mind making tomcat-connectors/util the master source for the
buffer stuff,
Hi,
A long mail, kind of important if you are interested in encodings. I'll
get most part checked in as soon as I finish running the tests and
removing the debug statements ( probably this weekend - I have a week of
vacation after that, with little computer time )
As you know, charsets and
On Thu, 24 May 2001, Dunlop, Aaron wrote:
First: We will need to cluster application servers in front of a central
database. We want the ability to add and remove servers from that farm in
real-time, without disturbing ongoing sessions. That either means storing
...
So that probably means
On Wed, 23 May 2001, Casey Lucas wrote:
btw, If i start tinkering, should I work with jasper34 or the 3.3 stuff?
Difficult question...
The problem with jasper34 is that it doesn't work yet ( the one in
proposals/jasper34 - I still have to move it in the new repository ). Mea
culpa - I tried
On Wed, 23 May 2001, Craig R. McClanahan wrote:
I know Costin loves evolutionary change :-), and it's certainly a valid
approach to Jasper.
But there is also another approach we should consider - a green-field
recoding of at least some of the major components (conforming to an
agreed-upon
Casey,
We hope to freeze 3.3 for a release in the next weeks. If you feel the
changes are reasonably small and will not create problems - you can still
do it.
What about:
1. We copy the code from 3.3 as it is in jasper34 area ( except that we
rename the package ).
2. We make sure it builds
On Tue, 22 May 2001, Rickard Öberg wrote:
Hi!
[EMAIL PROTECTED] wrote:
Could you send a small page ( and the taglibs ) and the test conditions ?
I have sent taglib+page and test conditions to Costin.
Thanks, I'll try to add it to the tests dir.
We know the pool is synchronized and
On Tue, 22 May 2001, Rickard Öberg wrote:
Hash lookup is done once per jsp page - when the jsp page is first run.
After that, it's basically a synchronized push / pop pair on all subsequent
runs of the page. In the future we can even get rid of the synch by using
thread local storage...
One thing to note about interceptors is that the behavior is intended to
be as close as possible with Apache modules, IIS filters and NES SAFs.
If you read the docs for the 3 web servers you'll notice an amazing
similarity between their extension mechanism ( which at least in Apache is
also the
Hi Rickard,
Could you send a small page ( and the taglibs ) and the test conditions ?
Most tests I run show a (significant) improvement in performance.
We know the pool is synchronized and that may create problems under heavy
load, and we know how to fix this ( by using a per/thread pool
Hi Filip,
I'm happy to see this happening ! Documentation is one of the weakest
points in tomcat, and I'm glad to see people willing to work on that.
Few general comments:
- licence. Tomcat is licenced under Apache, and from various reasons it's
not easy to bundle apache and gpl-licenced code.
Tim,
Thanks, great for the extra information.
One small corection - while the java chars are 16 bit, they can ( AFAIK
) represent the full 21 bits of unicode ( or 31 for iso-??? ). That's the
use of the surrogate chars ( d800 .. dbff if I got it right ), used to
combine 2 chars.
The %
Hi,
I've got a terible headache... It happens all the time I try to touch the
bugs related with encodings - any of them...
I'm sure you already know ( but I just found out ) what
surrogate characters are. I know that UTF is _not_ 16 bits, but I had no
idea it is 21 bits ( as opposed to UCS - 31
Vicent, Forrest,
Thanks for the patch review.
Could you summarize and/or expand a bit :-) ?
Also, does anyone played with the various browsers ? Is any browser
sending the charset encoding ? What format ?
I know that some browsers are encoding the URL with the same charset that
is used in
On Fri, 18 May 2001, Paulo Gaspar wrote:
In the case of DoS, I don't believe a bit on trusted tags and such
stuff. Why monitoring the tags at all if while(true) is so easy.
I mean, the front door is wide open, why care about that little
window?
Well, what I said was trusted tags and only
Vote to release the tomcat_32 branch as Tomcat 3.2.2.
[X] +1. I agree with the proposal and I will help support
the release.
[ ] +0. I agree with the proposal but I will not be able
to help support the release.
[ ] -0. I don't agree with the proposal but I won't stop
There is also a bug in 3.3 ( where URI is also decoded ),
I'm working on it - should be ready this weekend.
( I'm also working on the bug, it has the most votes so far )
Costin
On Fri, 18 May 2001, Keith Wannamaker wrote:
The 2.2 servlet spec errata says the uri from
On Thu, 17 May 2001, Christopher Kirk wrote:
From my view, the problem with JSP-Java-Class isn't performance its
debugging. JSP is hard to work with when you make a mistake, very often the
error message is less than helpful. A very large step in improving this is
by making the line number
Hi Carlos,
On Thu, 17 May 2001, Carlos Gaston Alvarez wrote:
I dont know if I really understood. You (some) are thinking to compile a
jsp using xslt. I didnt know that that was possible. I mean, can a jsp be
loaded as a dom object? I think that it cannot because a nice guy can write
On Thu, 17 May 2001, Paulo Gaspar wrote:
...
XSLT is not perfect - neither is HTTP or HTML or any other standard. But
because Apache and many other organizations are implementing and using it
- I think they'll be around for a while :-)
Costin
Costin,
You are still missing
On Thu, 17 May 2001, Craig R. McClanahan wrote:
On Thu, 17 May 2001 [EMAIL PROTECTED] wrote:
There is another solution - to generate the map ( java line number -
JSP source line number). This is exactly how the .class annotation works,
mapping bytecode to java source number. And
On Thu, 17 May 2001, Paulo Gaspar wrote:
There is another solution - to generate the map ( java line number -
JSP source line number). This is exactly how the .class annotation works,
mapping bytecode to java source number. And will allow you to see both
informations, and it's quite
On Thu, 17 May 2001, GOMEZ Henri wrote:
I would like to propose Jean-Frederic Clere as a new committer.
He make many contribution in jakarta-tomcat, jakarta-tomcat-4.0
and now in jakarta-tomcat-connectors, and we help us with
stuff like autoconf, APR and exotics systems :)
Vote
On Thu, 17 May 2001, Geir Magnusson Jr. wrote:
Really? I was told that it was a complete myth - that *no one* has to
debug the Java code - they just debug the JSP code. My JSP experience
occurred a few years agoe, and I remember bewildering error messages -
however, I just assumed that was
On Thu, 17 May 2001, Marc Saegesser wrote:
rant
These 2+ hour email delivery times are getting to be a real pain. It's
almost impossible to have multi-party communication with such delays.
/rant
3+ hours CVS update doesn't help either ( that's my current time on
xml-xalan, tomcat is
On Thu, 17 May 2001, Pier P. Fumagalli wrote:
Of all the ones who voted +1 is there someone who's going to do something
about it?
What do you mean by that ? To move the code in jakarata-tomcat-connectors?
I guess most of the people who voted +1 are going to work on
On Thu, 17 May 2001, Glenn Nielsen wrote:
This is the approach that Tea http://opensource.go.com/ uses as well as
the general idea behind taglibs. The problem with taglibs is that there is
no restriction on the ability to put Java code in the page. It is part of
the JSP specification to
On Thu, 17 May 2001, Glenn Nielsen wrote:
I guess he's refering to DOS attacks ( like a while(true); in java code
or allocating lots of memory ).
You won't have much of a templating language if you don't allow some
sort of looping. Kind of hard to restrict that.
True, but if you have a
On Tue, 15 May 2001, Jon Stevens wrote:
Currently Jasper output's Java code from within Java code. This is about as
fast as you are going to get because there is no intermediate transformation
step going on, just conditional output of String data entirely within Java.
While this is very
On Wed, 16 May 2001, Pier P. Fumagalli wrote:
[EMAIL PROTECTED] at [EMAIL PROTECTED] wrote:
[+1] Let's move mod_webapp and all its related stuff in jakarta-connectors.
+1 The stuff is not ready ( neither the new mod_jk for 4.0 nor mod_webapp
), and when it is - tomcat-dev should
On Wed, 16 May 2001, Jon Stevens wrote:
Costin,
Once again, you impress me with your inability to understand a word of what
I'm talking about. So, let me close this discussion with this:
No problem, I'm not that good at explaining either.
If the speed of generating a .java file (or
201 - 300 of 648 matches
Mail list logo
