Re: Embedded Tomcat

2005-09-30 Thread Rick Knowles

Eric Holk wrote:


I'm working on a project where I would like to run a simple web front end
for it. To save the time of implementing my own HTTP server I'd like to
embed Tomcat. I've read several documents on how to do this, and I've
managed to get Tomcat running inside my program. However, all the examples
I've seen show how to load a WAR file and use that as a web application. If
it's possible, I'd rather just have a sevlet class inside my program that
Tomcat uses rather than having an external web application.


You should be able to get away with just a single external file: a
web.xml file that mounts the servlet and maps it to a URI pattern. The
rest of the webapp code (ie the servlet class you mentioned) would be
able to be inside the main jar, because class loader inheritance would
cause the servlet class to be visible even if it's not in the
WEB-INF/classes folder.

If one external file is too many, you might need to do something tricky
to set the webapp's mounted instances from code. Maybe via JMX ? Someone
else might be able to help here 

Rick

--
Servlet v2.4 container in a single 155KB jar file ? Try Winstone 
(http://winstone.sourceforge.net/)



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



Re: Problems Parsing Request Paramers

2005-09-27 Thread Rick Knowles

Yoav Shapira wrote:


Hi,
Could it be the referer URL is too long, causing the query string to be ignored
or dropped?  There's a limit (2048 characters, I think?) on GET requests in
some browsers.  But actually, you're seeing this on the server, so I'm not
sure.  Can you try testing with less parameters or an otherwise shorter query
string?



I've seen this sort of thing too, but I thought it was 255 chars. From
RFC2616 section 3.2.1:

Note: Servers ought to be cautious about depending on URI lengths above
255 bytes, because some older client or proxy implementations might not
properly support these lengths. 

Not quite set in stone, but a good general hint to avoid long URLs.

Rick

--
Servlet v2.4 container in a single 155KB jar file ? Try Winstone 
(http://winstone.sourceforge.net/)



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



Jasper TCKing

2005-09-07 Thread Rick Knowles

All,

Not sure how to go about this, but I wanted to offer my services with
TCK compliance testing of tomcat/jasper.

I have been granted JSR 152 and 154 TCK karma for my own container
(winstone), and I figured since TCK karma is so hard to get, you guys
might appreciate having someone else who can share the responsibility
for tomcat. Obviously there would be some working out of communication
details because of TCK contract restrictions, but that shouldn't be
hard. It's in my interest to help with compliance because Jasper is
being used within Winstone - I've got it to pass all the JSR154 tests,
but the 152 tests were failing in a few places ...

I haven't been on this list for a while, so shoot me down if this is a
known problem - I ran the JSP TCK over jasper + tomcat 5.5.9, and
noticed that there were a few test failures when I ran it (four or so
that I counted in the api section). The main reason was that under
winstone I noticed the errors, so I tried running it against tomcat, and
got the same errors. It's possible they've been excluded and I've
misconfigured my test environment, so I well and truly leave open the
possibility it's my fault - just wanted to check.

Anyway, please let me know if the help is needed.

Rick

--
Servlet v2.4 container in a single 140KB jar file ? Try Winstone 
(http://winstone.sourceforge.net/)



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



Re: Jasper TCKing

2005-09-07 Thread Rick Knowles

Yoav,


Thank you for the offer.  It's certainly welcome.  We have TCK grants for these
APIs at Apache, and have had them for years. (In fact, the ASF has TCK rights
from Sun for virtually every API out there ;))  But as you've noted, it's a
time-consuming task, and in general we gladly welcome external help in all
areas.



Yes - I noticed the Apache Watchdog project heritage. Couldn't help but
laugh that Sun are charging for the same tests now (for commercial
vendors anyway) ...

The main thing I wanted to offer was to help with running it before
releases (which I think is part of the contract), and my understanding
is that only the individuals within the project that sign their lives
away to Sun are allowed access to the TCK, which I would guess isn't
everyone on the tomcat-dev team.


Would it be possible for you to run the TCK occasionally (as your time permits,
of course) on publicly-released Tomcat versions, and post the results either to
this mailing list or as a Bugzilla issue for Tomcat?  If not, we'll see what we
can work out.  There are some more private forums to which that information can
go, but the public route is preferred, to help our users with their QA and due
diligence tasks.



OK - no problem. Is it okay to post the results of TCK tests publicly
though ? I thought that wasn't allowed by the contract. I guess it
should be okay if I just publish the test groups and indexes that fail.

The tests that failed were:

jsp/api/javax_servlet/jsp/pagecontext: tests 15,28,30
jsp/api/javax_servlet/jsp/tagext/simpletagsupport: test 7
jsp/spec/core_syntax/actions/invoke: test 7
jsp/spec/core_syntax/implicitobjects: test 3
jsp/spec/tagfiles/semantics: tests 1,2,3,4

Note this is 5.5.9, so possibly already fixed.

Rick

--
Servlet v2.4 container in a single 140KB jar file ? Try Winstone 
(http://winstone.sourceforge.net/)



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



Re: AW: DefaultServlet and getOutputStream() / getWriter()

2004-10-09 Thread Rick Knowles
Steffen,
My understanding (and I might be wrong here, so someone please correct 
me if I am) is that once you've called getWriter(), you can't call 
getOutputStream() on the same request. The reason is primarily so that 
you have to use the same char encoding etc on included servlets as in 
the including servlet.

Calling getOutputStream after getWriter results in an exception being 
thrown in Tomcat, hence the try/catch.

Rick Knowles
PS And for the record, I thought Remy's response was pretty harsh too.
Steffen Heil wrote:
Hi
 

That's definitely why I am not interested by code cleanups done by folks
   

who might not know all the small tricks: the risk of breaking stuff is far
greater than the gain.
Why are you soo hostile?
I am just trying to get into the code and if I understand it, I will
propably start to contribute something. But I need to start somewhere and I
cannot know all the small tricks from beginning. THAT IS WHY I AM ASKING!
I did not say remove that shit, nor did I say this is stupid. I just
asked why it is done that way.
Additionally, every change I suggested (on tomcat-user) was definitly not
changing any behaviour, but maybe improving performance.
So I need to give that back to the authors. Things that are not self-evident
should be documented in code. There is nothing.
And again, please see, that this is no allegation. But someone will know it
and it is not in the code, so you should accept questions.
You told me:
 

... submit more significant patches ...
   

How should I, if I cannot even get information about easy things?
 

For this particular case, you should look into the API javadocs.
   

That's what I have done for some hours.
Returns a ServletOutputStream suitable for writing binary data in the
response. The servlet container does not encode the binary data. 
java.lang.IllegalStateException - if the getWriter method has been called on
this response 
java.io.IOException - if an input or output exception occurred

If I believe that javadocs, THERE IS NO REASON to do what the code does,
sind getWriter is never called before getOutputStream, so there will never
be the IllegalStateException and half of the code is obsolete.
That is exactly the reason I am asking.
Regards,
 Steffen
 

--
Servlet v2.4 container in a single 140KB jar file ? Try Winstone 
(http://winstone.sf.net/)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Request dispatching question

2004-08-04 Thread Rick Knowles
Tomcat devs,
I've noticed an interesting behaviour when moving some webapp code from 
Winstone to Tomcat, and I'd like to get an opinion on whether what it's 
by design, accidental or I've misinterpreted the spec (equal likelihood 
of any of the above).

The webapp implements access control using a filter and a request 
wrapper. The filter is mapped to the protected directory, and any 
request that passes through gets checked for a token. If the token is 
not found, it dumps the contents of the request into a session object, 
and forwards to the login servlet. After the login is approved, the 
token is set, and a client side redirect to the original location is 
sent with a key added. On this second pass through the filter, the key 
is used to look up the session object storing the details of the 
original request. The filter constructs a request wrapper from that 
session object that makes the new request mimic the original one (eg 
when getRequestURI is called, it returns what the pre-authentication 
request's uri was, same for getServletPath, etc)

This approach seems to work well with the first servlet, but if that 
servlet forwards to another servlet, it breaks down. It seems like on a 
forward, Tomcat sees that the request object it is handling is not the 
CoyoteRequestFacade and doesn't bother trying to reset the pathInfo, 
servletPath etc, so forwarding to a JSP seems to fail.

It works ok on Winstone, because on a forward it unwraps the request 
until it hits something that's not a wrapper, resets the 
pathInfo/servletPath/etc, and passes it into the filter chain. It seems 
(from the outside) like Tomcat doesn't try more than one unwrap attempt. 
All of this is without yet looking at Tomcat source, so if I'm making a 
fool of myself just point me at a file and I'll disappear.

My question is this (sorry I took so long to get to it) - what is the 
correct behaviour here ? Should it unwrap all the way, or only one step 
? Is the behaviour I'm seeing expected or is something wrong ?

Thanks in advance,
Rick Knowles
--
Servlet v2.4 container in a single 140KB jar file ? Try Winstone 
(http://winstone.sf.net/)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: port number at runtime

2004-07-20 Thread Rick Knowles
Having this as a requirement makes an awful lot of assumptions about the 
architecture of the container, none of which are helpful in the larger 
scale. For example, what if you have 2 (or 50) http connectors and the 
same for https ? And then what about ajp13 ? Or mod_caucho's protocol (I 
think it's called hessian) ? The reason this is not in the servlet api 
spec is because it would create more problems than it would solve.

There are some cases where you just need to know what your deployment 
environment is going to be ... this is one of them.

Rick
saugata ghosh wrote:
request.getServerPort()
-Thanks, but this returns the port number of the
current request port.
But my problem is, say the request is for http: and I
want to redirect to https:/.../somefile.jsp. - then ?
Basically what is required is a method that will
return the port number set in the conf/server.xml
file.
-Saugata
 

--
Servlet v2.4 container in a single 140KB jar file ? Try Winstone
(http://winstone.sourceforge.net)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Embedding Jasper / JSP compiling

2004-06-06 Thread Rick Knowles
Remy,
So now that you have learnt, are you more ineterested in using the TC 
connectors ? Casually looking at the HTTP code, I can say it is not 
especially efficient (and really optimizing this part is rather long 
and painful).
If you want to join this project, your servlet API implementation 
could become an alternative to Catalina (I know the idea floated 
around on a few occasions in the past).

Rémy
I've been thinking a lot about this over the last few days about this, 
and I think the best answer to give is thanks for the offer, but not 
just yet.

Having watched this list for the last month or so now, I can anticipate 
there would be clashes in working style and priorities that would be 
more hassle than they were worth for all involved. I know it sounds 
selfish, but I guess I'm just enjoying having this as a solo project too 
much to give it up yet.

I think the best plan would be to wait until I feel Winstone has reached 
its end point (in terms of what I can give it), and then just donate it 
so you guys can replace whatever you want.

Thanks again for the offer ... it was very tempting, but knowing the way 
I work, I'd say not good in the long term.

Rick
-
Servlet v2.4 container in a single 140KB jar file ? Try Winstone 
(http://winstone.sf.net/)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Hypothetical

2004-06-06 Thread Rick Knowles

As for the orininal question: you cannot support scriplets without 
compiling. I know Kin-Man has entertained the idea of using straight 
code generation for tags-only pages, but assuming the 
super-duper-compiler from the JCP shows up, the incentive isn't very big.

Rémy
Thanks - this is exactly the kind of gotcha I was hoping someone would 
point out. Much appreciated.

Rick
-
Servlet v2.4 container in a single 140KB jar file ? Try Winstone 
(http://winstone.sf.net/)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Hypothetical

2004-06-03 Thread Rick Knowles
Tomcat dev types,
This is not a request for enhancement or change in any way, just seeking 
an opinion on an idea.

Has BCEL ever been considered for use with in a JSP compiler like Jasper 
? I'm currently toying with trying to start a new JSP compiler project 
to go with Winstone (servlet engine), and so started looking at things 
like XSLTC for ideas. I noticed it was using BCEL, and in doing so 
avoided the need for more than a JRE.

Do any of you know of a JSP compiler already existing that uses this 
approach ? More importantly  do any of you know of a reason why this 
would be a bad idea ?

Any comments would be appreciated. Thanks in advance,
Rick Knowles
-
Servlet v2.4 container in a single 140KB jar file ? Try Winstone 
(http://winstone.sf.net/) http://winstone.sourceforge.net/

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


Re: Hypothetical

2004-06-03 Thread Rick Knowles
Yoav,
You know Servlet Spec compatibility requires env-entry/resource-ref
support and therefore at least a slim JNDI implementation...
Yoav Shapira
Millennium Research Informatics
 

Thanks for the reply. 

I've only just (as in this morning) received a reply from the JCP people saying I'd be sent a 
TCK soon. Until then, I figure it's ok to say it's spec compliant as long as it 
works with all the apps I've tested, and I tell everyone I haven't run the TCK tests yet. Maybe 
in another month the JCP people will send me the TCK ... until then though, not much I can do.
Interesting though - the spec says:
quote from p104 section 13.1
The following additional elements exist in the Web application deployment descriptor 
to meet the requirements of Web containers that are JSP pages enabled or part of a 
J2EE application server. They are not required to be supported by containers wishing 
to support only the servlet specification:
 jsp-config
 Syntax for looking up JNDI objects (env-entry, ejb-ref, ejb-local-ref, resource-ref, 
resource-env-ref)
 Syntax for specifying the message destination (message-destination, 
message-destination-ref)
 Reference to a Web service (service-ref)
/quote from p104 section 13.1
I wasn't planning for Winstone to be a full J2EE compliant container, so I took this 
to mean resource-ref, et al were optional. Did I read it wrong ?
Rick Knowles
-
Servlet v2.4 container in a single 140KB jar file ? Try Winstone 
(http://winstone.sf.net/)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Hypothetical

2004-06-03 Thread Rick Knowles
Yoav,
I think you read it correctly, and interpreted it correctly.  It's a
distinction between the Servlet and JSP specifications.  You just have
to be careful to mention those sort of things up front, as people might
expect those features from a Servlet v2.4 container (because all other
servlet containers I know of do support these features, and very few
people know the spec by heart).
 

This is a fair point. I'll change the doc to something a little clearer. Or maybe I'll 
just implement the remaining pieces as components for the full jar set only (ie the 
non-lite version).
Thanks again,
Rick
-
Servlet v2.4 container in a single 140KB jar file ? Try Winstone 
(http://winstone.sf.net/)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Tomcat 5.0.25 does not honor error-page directive?

2004-05-27 Thread Rick Knowles
What does the rest of the web.xml look like ... could it be an order 
thing (DTDs impose ordering on the elements) ? Which DTD/XSD did you use ?

Rick Knowles
Detlef Pleiß wrote:
In a freshly unzipped jakarta-tomcat-5.0.25 installation I added 

error-page
error-code404/error-code
location/404.html/location
/error-page
(copied from servlet-2_4-fr-spec.pdf page 153)
Just before the closing /web-app in webapps/ROOT/WEB-INF/web.xml
I then copied a simple 404.html file to webapps/ROOT.
However, when requesting some non existing page like
http://127.0.0.1:8080/blub.jsp
I get the standard browser 404 error page (in my case MSIE) not my 404.html.
Is this a bug?
Ciao - thanks - Det.
-
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: Tomcat 5.0.25 does not honor error-page directive?

2004-05-27 Thread Rick Knowles
Sorry - just checked the file. There's only servlet and servlet-mapping 
elements. My bad

Rick Knowles
Detlef Pleiß wrote:
In a freshly unzipped jakarta-tomcat-5.0.25 installation I added 

error-page
error-code404/error-code
location/404.html/location
/error-page
(copied from servlet-2_4-fr-spec.pdf page 153)
Just before the closing /web-app in webapps/ROOT/WEB-INF/web.xml
I then copied a simple 404.html file to webapps/ROOT.
However, when requesting some non existing page like
http://127.0.0.1:8080/blub.jsp
I get the standard browser 404 error page (in my case MSIE) not my 404.html.
Is this a bug?
Ciao - thanks - Det.
-
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: Embedding Jasper / JSP compiling

2004-05-14 Thread Rick Knowles
Dennis,

I'm not a tomcat dev, but hopefully I can help anyway - having done what 
I think it is you're trying to do. I did mine for the Winstone servlet 
container (http://winstone.sourceforge.net)

For Nos 1 and 2, I can't help. But for No 3 it involves setting context 
attributes:
1) org.apache.catalina.jsp_classpath, and
2) org.apache.catalina.classloader

It seems that 1 is the one that does the work. It doesn't actually even 
seem to call 2 at class load time, but there is code that reads 2, so I 
set it anyway.

By setting 1, you don't actually set the classloader, but you make a new 
classloader that has the same classpath. If that's not what you want, 
maybe someone else on the list can help.

The only other thing you have to do is mount the JspServlet, which it 
sounds like you've already done.

R

Dennis Thrysøe wrote:

Hi,

I'm currently working on embedding a jasper engine within a servlet 
container that I'm writing. During this work I have run into the 
following questions:

1) Is the only advantage to using fork=true, that the javac memory 
leak issue is avoided?

2) Has the javac memory leak issue been fixed in newer versions of the 
JDK?

3) Is there any way to have the Java code generated from JSPs compiled 
using my own classloader? I was thinking, that if I used fork=false, 
maybe javac would just use the present classloader.

Any help with the above questions would be greatly appreciated, since 
it seems that I'm on a fairly difficult endeavour here.

TIA,

-dennis

-
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: ajp13 file upload bug

2001-03-07 Thread Rick Knowles

I also had this problem, although I was using my own Multipart Handler class
based on Javamail. The upload works correctly using ajp12, but puts
jibberish in the logs when ajp13 is substituted in.

R
- Original Message -
From: "Stefan Busse" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, March 07, 2001 11:47 PM
Subject: ajp13 file upload bug


 here we go... btw our system is Solaris 2.8 on Intel / Apache 1.3.17,
 compiled with gcc-2.95.2. Tomcat is run by jdk1.3. Maybe the problem
 is related with assumptions about header-sizes implemented in ajp13 ?

  Can you post this to the tomcat-dev mailing list?
 
  -jh-
 
  Stefan Busse wrote:
 
  Hi Jason,
 
  just stumbled across your post while looking for an answer for my
  own upload problems. In fact there seems to be an ajp13 bug. I just
  tried your demo-application because my own (primitive) upload-servlet
  stopped working when I switched from resin (connected through
mod_caucho)
  to tomcat 3.2.1 (connected through mod_jk). Maybe ajp13 can't handle
  multipart-contents. There is no error in the logfiles, the servlet
  just seems to be stuck in a loop, as the browser uploads forever.
 
  Hope this helps, or maybe you can forward this to the wizard
  developing the ajp13-connector...
 
  * stefan busse
 
  --
  To: [EMAIL PROTECTED]
  Subject: Possible ajp13 bug doing file upload posts
  From: Jason Hunter [EMAIL PROTECTED]
  Date: Sun, 07 Jan 2001 19:40:17 -0800
  
 
  Hi,
 
  Here's a bug report in ajp13 from someone using my com.oreilly.servlet
  package to do file uploads.  No real details, but I'm thinking perhaps
  someone with ajp13 running can test the file upload example?  You can
  download the c.o.s. pkg from
  http://www.servlets.com/resources/com.oreilly.servlet.  I'm happy to
  provide support.
 
  -jh-


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



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




Re: Some benchmarks

2001-03-05 Thread Rick Knowles

I know some guys at probably the biggest dot com in Japan (fill in the
blanks), who tried out servlet engines looking for the elusive
"next-generation" engine.
They said they tried Weblogic, JRun and another one I can't remember as well
as tomcat. they found that with the same code, they were able to serve a
maximum of 55 million ad banners of up to 100KB per day with Tomcat (I think
v3.0 or 3.1), compared with weblogic and jrun neither of which cracked 45
million (can't remember exact figures, but a significant difference). They
also commented that tomcat had less memory leaks and crashed half as often.
They were in the process of switching to Catalina when I spoke to them.

Moral of the story is  well done guys :).

R

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