Embedded Tomcat
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. I haven't found any examples for how to do this, and I haven't been able to figure it out from the JavaDocs. Does anyone have ideas for how to do this? Thanks, Eric Holk
Re: Embedded Tomcat
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]
DO NOT REPLY [Bug 32031] - Can't create http connector for an Embedded tomcat
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32031. 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=32031 Can't create http connector for an Embedded tomcat [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-11-03 12:02 --- Those calls are not very useful IMO, but it's now fixed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: (Case 69726) DO NOT REPLY [Bug 32031] -Can't create http connector for an Embedded tomcat
Hello, This is an automatic notification to inform you that your inquiry has been received and assigned case number 69726. Your request is important to us and we are committed to responding to your requests as quickly as we can. We answer e-mail on a first-in, first-out basis. If you wish to submit any new information on your query, simply reply to this e-mail and type your new message at the top of the e-mail message area. Please make sure you mention Case 69726 in your Subject line when you follow-up on your inquiry. Thank you, Mabry Software Technical Support - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32031] New: - Can't create http connector for an Embedded tomcat
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32031. 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=32031 Can't create http connector for an Embedded tomcat Summary: Can't create http connector for an Embedded tomcat Product: Tomcat 5 Version: 5.5.4 Platform: Other OS/Version: Other Status: NEW Severity: Critical Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Embedded embedded = ... ... embedded.createConnector((InetAddress)null, 8080, false); This last call logs this message : Couldn't create connector. It seems that the method : public Connector createConnector(String address, int port, String protocol) return always null when the protocol is http. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32031] - Can't create http connector for an Embedded tomcat
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=32031.
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=32031
Can't create http connector for an Embedded tomcat
--- Additional Comments From [EMAIL PROTECTED] 2004-11-02 22:19 ---
I Have fixed the bug like this :
if (protocol.equals(ajp)) {
connector = new Connector(org.apache.jk.server.JkCoyoteHandler);
} else if (protocol.equals(memory)) {
connector = new Connector
(org.apache.coyote.memory.MemoryProtocolHandler);
} else {
connector = new Connector();
if (protocol.equals(https)) {
connector.setScheme(https);
connector.setSecure(true);
// FIXME SET SSL PROPERTIES
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30583] - Cannot switch of tld scan for Embedded tomcat
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30583. 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=30583 Cannot switch of tld scan for Embedded tomcat [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-08-31 14:53 --- OK, feature added. StandardContext now has a processTlds attribute which you can set to false in your use-case. I also took processTlds() out of the big start() method so that classes extending StandardContext can easily modify processTlds behavior. All of this will be available in Tomcat 5.0.29 and 5.5.0. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30624] - unable to load tiles-definition.war when running embedded tomcat
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30624. 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=30624 unable to load tiles-definition.war when running embedded tomcat [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-08-30 20:33 --- I've added better null checking in RealmBase#findSecurityConstraints on both the TOMCAT_5_0 and CVS HEAD branches. Thanks for pointing this out. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30624] New: - unable to load tiles-definition.war when running embedded tomcat
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30624. 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=30624 unable to load tiles-definition.war when running embedded tomcat Summary: unable to load tiles-definition.war when running embedded tomcat Product: Tomcat 5 Version: 5.0.27 Platform: PC OS/Version: Windows XP Status: NEW Severity: Blocker Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I was prototyping using tomcat embedded in my java application. Was trouble having launch a webapp based on tiles/struts. i got this error when i tried to run the standard example of tiles-definiton.war. This war properly loads when running tomcat as a stand alone web container. java.lang.NullPointerException at org.apache.catalina.realm.RealmBase.findSecurityConstraints (RealmBase .java:428) at org.apache.catalina.authenticator.AuthenticatorBase.invoke (Authentica torBase.java:455) at org.apache.catalina.core.StandardValveContext.invokeNext (StandardValv eContext.java:102) at org.apache.catalina.core.StandardPipeline.invoke (StandardPipeline.jav a:520) at org.apache.catalina.core.StandardHostValve.invoke (StandardHostValve.j ava:137) at org.apache.catalina.core.StandardValveContext.invokeNext (StandardValv eContext.java:104) at org.apache.catalina.valves.ErrorReportValve.invoke (ErrorReportValve.j ava:117) at org.apache.catalina.core.StandardValveContext.invokeNext (StandardValv eContext.java:102) at org.apache.catalina.core.StandardPipeline.invoke (StandardPipeline.jav a:520) at org.apache.catalina.core.StandardEngineValve.invoke (StandardEngineVal ve.java:109) at org.apache.catalina.core.StandardValveContext.invokeNext (StandardValv eContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke (StandardPipeline.jav a:520) at org.apache.catalina.core.ContainerBase.invoke (ContainerBase.java:929) at org.apache.coyote.tomcat5.CoyoteAdapter.service (CoyoteAdapter.java:16 0) at org.apache.coyote.http11.Http11Processor.process (Http11Processor.java :799) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.proce ssConnection(Http11Protocol.java:705) at org.apache.tomcat.util.net.TcpWorkerThread.runIt (PoolTcpEndpoint.java :577) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run (ThreadP ool.java:683) at java.lang.Thread.run(Thread.java:534) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30624] - unable to load tiles-definition.war when running embedded tomcat
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30624. 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=30624 unable to load tiles-definition.war when running embedded tomcat --- Additional Comments From [EMAIL PROTECTED] 2004-08-12 17:09 --- Created an attachment (id=12409) the java file that i compile to run tomcat embedded - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30583] New: - Cannot switch of tld scan for Embedded tomcat
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30583. 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=30583 Cannot switch of tld scan for Embedded tomcat Summary: Cannot switch of tld scan for Embedded tomcat Product: Tomcat 5 Version: 5.0.27 Platform: PC OS/Version: Linux Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hi, I'm using the Embedded tomcat 5.0.27 for servlets only. So a minimalistic setup is ok. When starting up, the StandardContext does a TLD scan, which fails als it finds a TLD, which is not meant to be used in this setup: java.lang.NullPointerException at org.apache.catalina.startup.DigesterFactory.register(DigesterFactory.java:174) at org.apache.catalina.startup.DigesterFactory.registerLocalSchema(DigesterFactory.java:130) at org.apache.catalina.startup.DigesterFactory.newDigester(DigesterFactory.java:92) at org.apache.catalina.startup.TldConfig.createTldDigester(TldConfig.java:408) at org.apache.catalina.startup.TldConfig.tldScanStream(TldConfig.java:508) at org.apache.catalina.startup.TldConfig.tldScanJar(TldConfig.java:472) at org.apache.catalina.startup.TldConfig.execute(TldConfig.java:307) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4282) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1083) at org.apache.catalina.core.StandardHost.start(StandardHost.java:789) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1083) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:478) at org.apache.catalina.startup.Embedded.start(Embedded.java:846) at com.coremedia.servlet.tomcat.EmbeddedTomcat.start(EmbeddedTomcat.java:118) Please consider making the TLD scan optional, as thought about in StandardContext: org.apache.catalina.core.StandardContext, line 4260ff // Read tldListeners. XXX Option to disable TldConfig tldConfig = new TldConfig(); tldConfig.setContext(this); The workaround to overwrite this large start() method is not very elegant and error prone. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
embedded tomcat and JMX sample code
I am looking for some sample code that will demonstrate how to embed tomcat in a java application using JMX. I would like to write some documentation on how to do this, as there is none that exists that I have found on tomcat's web site. I would imagine that there must be some code somewhere that was used for testing the new infrastructure. Everywhere I have turned so far, has told me to look at the JBoss source code, but I figure that the tomcat development team must have some code laying around that will demonstrate this. thank you for your time. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: embedded tomcat and JMX sample code
Mark W. Webb wrote: I am looking for some sample code that will demonstrate how to embed tomcat in a java application using JMX. I would like to write some documentation on how to do this, as there is none that exists that I have found on tomcat's web site. I would imagine that there must be some code somewhere that was used for testing the new infrastructure. Everywhere I have turned so far, has told me to look at the JBoss source code, but I figure that the tomcat development team must have some code laying around that will demonstrate this. The Ant script in the embed distribution can directly be translated into JMX commands. Other than that, we have no Java JMX code (so look in the JBoss/Tomcat integration for that). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23881] - SingleSignOn and FormAuthenticator in embedded tomcat
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23881. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23881 SingleSignOn and FormAuthenticator in embedded tomcat --- Additional Comments From [EMAIL PROTECTED] 2003-12-24 20:42 --- I have applied you patch to TC4. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23881] - SingleSignOn and FormAuthenticator in embedded tomcat
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23881. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23881 SingleSignOn and FormAuthenticator in embedded tomcat --- Additional Comments From [EMAIL PROTECTED] 2003-12-24 06:44 --- Created an attachment (id=9694) Previous patch to 4.1 updated to avoid conflict with patch applied today by Mark Thomas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23881] - SingleSignOn and FormAuthenticator in embedded tomcat
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23881. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23881 SingleSignOn and FormAuthenticator in embedded tomcat --- Additional Comments From [EMAIL PROTECTED] 2003-12-24 06:48 --- Patch attached a moment ago is a zip file which includes a diff plus a new class. The new class is just the existing SingleSignOnEntry inner class extracted out of SingleSignOn. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23881] - SingleSignOn and FormAuthenticator in embedded tomcat
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23881. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23881 SingleSignOn and FormAuthenticator in embedded tomcat [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2003-12-07 19:27 --- *** Bug 4350 has been marked as a duplicate of this bug. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23881] - SingleSignOn and FormAuthenticator in embedded tomcat
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23881. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23881 SingleSignOn and FormAuthenticator in embedded tomcat --- Additional Comments From [EMAIL PROTECTED] 2003-11-26 04:53 --- Created an attachment (id=9288) Port of the TC5 patch to TC 4.1; includes related fix to 9077 and 10040 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23881] - SingleSignOn and FormAuthenticator in embedded tomcat
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23881. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23881 SingleSignOn and FormAuthenticator in embedded tomcat [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-11-24 16:53 --- I have applied your patch, thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23881] - SingleSignOn and FormAuthenticator in embedded tomcat
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23881. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23881 SingleSignOn and FormAuthenticator in embedded tomcat [EMAIL PROTECTED] changed: What|Removed |Added Product|Tomcat 4|Tomcat 5 Version|4.0 Beta 1 |5.0.14 --- Additional Comments From [EMAIL PROTECTED] 2003-11-23 17:45 --- I think I'm going to apply this patch. Esp since it has been tested in JB land first (otherwise, I wouldn't want to commit it so close to a release). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23881] - SingleSignOn and FormAuthenticator in embedded tomcat
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23881. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23881 SingleSignOn and FormAuthenticator in embedded tomcat --- Additional Comments From [EMAIL PROTECTED] 2003-11-23 00:01 --- Created an attachment (id=9247) Patch w/ diff and one new class - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23881] - SingleSignOn and FormAuthenticator in embedded tomcat
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23881. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23881 SingleSignOn and FormAuthenticator in embedded tomcat --- Additional Comments From [EMAIL PROTECTED] 2003-11-23 00:18 --- Attached is a proposed patch. It adds a configurable attribute requiresReauthentication to SingleSignOn. If false (the default), applications will behave as they do now. If true, each incoming request will need to be reauthenticated to the Realm. The various authenticators have been modified to handle this. In this case the SingleSignOnEntry serves as a store of authentication credentials. If the 1st webapp a user visits uses FORM or BASIC auth, and then they visit another app that requires DIGEST, the cached username/password from the FORM/BASIC authentication will not be sufficient information to do a digest authentication, so the user will be prompted for a digest login. Possibly we could add a config option to allow a username/password authentication to override the DIGEST auth specified in the web.xml. Similarly, if the user first visits a webapp with DIGEST auth, and then visits one that uses FORM or BASIC, again the cached credentials will not be sufficient (no cached password from the digest auth), so they will have to be prompted for their username/password. The attached patch includes logic that deals with all this and ensures that a single SSO session is maintained throughout. Of course, if webapps in a deployment don't mix their authentication schemes, none of the above details are an issue. This bug was raised against TC 4; sorry the patch is against TC 5. I can very easily pull together a TC4.1 version if desired. This patch also addresses bug 10040. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Embedded Tomcat
I've successfully embedded Tomcat into my application and have talked to a few people about how to shared objects between the application and the JSPs from the contexts I've defined. I've had a suggested to use JNDI but this seems a little more elaborate than I need, and someone else was talking about using ServletContext.setAttribute() and ServletContext.getAttribute() Is there a code example both application side and web side somewhere that could show me how to do this? I've been wrestling with this for a while and it's starting to irritate me. :) I've embedded Tomcat for the sole purpose of being able to create JSPs and Servlets that can examine the properties of the application and modify the properties as well. For example, I need to be able to do the following in my JSP. MyApplication app = someway of getting access to the instantiated object; Object obj = app.getSomeData(); obj.modifyInSomeWay(); app.setSomeData(obj); If anyone can provide an example for this, I would very much appreciate it. Thanks. -- Robert Charbonneau [EMAIL PROTECTED] -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Embedded Tomcat
Hi Robert,
Congratulations on having Embedded Tomcat in your application.
My apologies for not explaining a solution to your problem more clearly.
The method we had discussed by private mail earlier today indeed works. I
cannot give you actual source code, simply because I'm downloading Tomcat at
the moment.
The only part that you need to work on is the :
MyApplication app = someway of getting access to the instantiated object;
that you have mentioned below:
Let's say your application (with all its parts) is represented by
MyApplication.
You could create the class along the lines of :
public class MyApplication{
private static MyApplication currentInstance = null;
private MyApplication(){
}
public MyApplication getCurrentInstance(){
if (currentInstance==null){
currentInstance = new MyApplication();
initialize(); // some initialization work
}
return currentInstance;
}
}
You should now be able to access MyApplication's object from within your web
applications via MyApplication.getCurrentInstance();
In your care, you do not need JNDI. There is another means of sharing objects
(via JMX) that I shall explore once this Tomcat download is completed.
-- Sriram
--- Robert Charbonneau [EMAIL PROTECTED] wrote:
I've successfully embedded Tomcat into my application and have talked to a
few
people about how to shared objects between the application and the JSPs from
the contexts I've defined. I've had a suggested to use JNDI but this seems a
little more elaborate than I need, and someone else was talking about using
ServletContext.setAttribute() and ServletContext.getAttribute()
Is there a code example both application side and web side somewhere that
could show me how to do this? I've been wrestling with this for a while and
it's starting to irritate me. :)
I've embedded Tomcat for the sole purpose of being able to create JSPs and
Servlets that can examine the properties of the application and modify the
properties as well. For example, I need to be able to do the following in my
JSP.
MyApplication app = someway of getting access to the instantiated object;
Object obj = app.getSomeData();
obj.modifyInSomeWay();
app.setSomeData(obj);
If anyone can provide an example for this, I would very much appreciate it.
Thanks.
--
Robert Charbonneau
[EMAIL PROTECTED]
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
__
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
http://launch.yahoo.com/promos/britneyspears/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Embedded Tomcat startup java class
Mark W. Webb wrote: Knowing that Tomcat is moving towards JMX, I was wondering if anyone has ported Embedded.java into the a format that will support the JMX integration. Knowing that there is a build.xml file that will launch tomcat in an embedded state, is there an equivalent .java file for doing this? You don't have to do that. You can use Embedded to create your TC instance, and then use JMX to create or destroy contexts. Or use a standalone TC with a server.xml, and use JMX (or Embedded) to manage the contexts (that's how it works in the integrated JBoss 3.2 / TC 5). You can mix and use whatever seems best to you :) Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Embedded Tomcat startup java class
Knowing that Tomcat is moving towards JMX, I was wondering if anyone has ported Embedded.java into the a format that will support the JMX integration. Knowing that there is a build.xml file that will launch tomcat in an embedded state, is there an equivalent .java file for doing this? thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23881] New: - SingleSignOn and FormAuthenticator in embedded tomcat
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23881. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23881 SingleSignOn and FormAuthenticator in embedded tomcat Summary: SingleSignOn and FormAuthenticator in embedded tomcat Product: Tomcat 4 Version: 4.0 Beta 1 Platform: All OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] SingleSignOn valve and FormAuthenticator fail to authenticate correctly when Tomcat works as embedded engine using a jaas realm (jboss). SingleSignOn code wrongly sets the principal inside request based on his cookie and FormAuthenticator just thinks everything is ok. In fact FormAuthenticator has to call authenticate again using the 'username' and 'password' stored inside the entry for that ssoId (value of the cookie). One way to fix it is to set only the request REQ_SSOID_NOTE (not the principal too) inside SingleSignOn valve. FormAuthenticator has to make a SingleSignOn lookup, retrieve the username and password and call authenticate. This should happen after checking (unsuccessfully) the credentials stored inside the session. This kind of fix made it working for me , although the code is still somewhat not optimal - (associate is called way to often, and the same for register , which will reset the cookie) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23881] - SingleSignOn and FormAuthenticator in embedded tomcat
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23881. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23881 SingleSignOn and FormAuthenticator in embedded tomcat --- Additional Comments From [EMAIL PROTECTED] 2003-10-17 09:08 --- also the register method in AuthenticatorBase creates a new cookie for SingleSignOn - i guess should check against an already existing cookie (using lookup) - and just call method associate in case this one exists. this solves a potential memory leak and the logout issue (register is called after every successful authenticate with the container realm). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Embedded tomcat with HTTPS
I'm going to assume that you're using 4.1.x. In this case, you are using the wrong Factory. You want something like: Connector httpsConnector = embeddedTomcat.createConnector(null, configuration.getHttpsPort(), true); CoyoteServerSocketFactory serverSocketFactory = (CoyoteServerSocketFactory)httpsConnector.getFactory(); serverSocketFactory.setKeystoreFile(configuration.getKeystoreFile()); serverSocketFactory.setKeystorePass(antares); - Original Message - From: Wesley Hall [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, August 10, 2003 1:23 PM Subject: Embedded tomcat with HTTPS Hello, Myself and a collegue are currently working on an open source application, part of which involves embedding a servlet engine. I have read through some tutorials and the API docs for tomcat and began development of a class structure to provide this. I have, however come across a problem with my https connector. I currently have code that looks like this.. Connector httpsConnector = embeddedTomcat.createConnector(null, configuration.getHttpsPort(), true); httpsConnector.setScheme(https); SSLServerSocketFactory serverSocketFactory = new SSLServerSocketFactory(); serverSocketFactory.setKeystoreFile(configuration.getKeystoreFile()); serverSocketFactory.setKeystorePass(antares); httpsConnector.setFactory(serverSocketFactory); embeddedTomcat.addConnector(httpsConnector); connectors.add(httpsConnector); configuration is a instance of a simple bean, getHttpsPort() returns 443, getKeystoreFile() returns the path to the keystore (generated as per the SSL-Howto doc). The location of the keystore is validated elsewhere in the code using a File object and a call to .isFile() and .canRead(), both of which return true when running this code. However... i am finding that although http://localhost:443 works perfectly, https://localhost leaves the browser (MSIE) whirring away for 30 seconds or so before displaying 'cannot find server'. With the former i get plenty of information in the logs but the latter adds nothing at all to the logs, making this problem very difficult to debug. I can change the keystore pass to any value and there is no appreciable difference. Im happy to provide any more information as required... Would a kind sameritan type point me in the write direction as to what may be causing this issue? Regards Wesley I. Hall. P.S. I thought long and hard on whether this belonged on dev or user, but since we are discussing actually class structure i finally decided that dev would probably be more appropriate. If i was wrong on that descision, you have my sincere apologies. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Embedded tomcat with HTTPS
Hello, Myself and a collegue are currently working on an open source application, part of which involves embedding a servlet engine. I have read through some tutorials and the API docs for tomcat and began development of a class structure to provide this. I have, however come across a problem with my https connector. I currently have code that looks like this.. Connector httpsConnector = embeddedTomcat.createConnector(null, configuration.getHttpsPort(), true); httpsConnector.setScheme(https); SSLServerSocketFactory serverSocketFactory = new SSLServerSocketFactory(); serverSocketFactory.setKeystoreFile(configuration.getKeystoreFile()); serverSocketFactory.setKeystorePass(antares); httpsConnector.setFactory(serverSocketFactory); embeddedTomcat.addConnector(httpsConnector); connectors.add(httpsConnector); configuration is a instance of a simple bean, getHttpsPort() returns 443, getKeystoreFile() returns the path to the keystore (generated as per the SSL-Howto doc). The location of the keystore is validated elsewhere in the code using a File object and a call to .isFile() and .canRead(), both of which return true when running this code. However... i am finding that although http://localhost:443 works perfectly, https://localhost leaves the browser (MSIE) whirring away for 30 seconds or so before displaying 'cannot find server'. With the former i get plenty of information in the logs but the latter adds nothing at all to the logs, making this problem very difficult to debug. I can change the keystore pass to any value and there is no appreciable difference. Im happy to provide any more information as required... Would a kind sameritan type point me in the write direction as to what may be causing this issue? Regards Wesley I. Hall. P.S. I thought long and hard on whether this belonged on dev or user, but since we are discussing actually class structure i finally decided that dev would probably be more appropriate. If i was wrong on that descision, you have my sincere apologies. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15403] New: - Embedded Tomcat can't compile JSP .java file due to extra /
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15403. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15403 Embedded Tomcat can't compile JSP .java file due to extra / Summary: Embedded Tomcat can't compile JSP .java file due to extra / Product: Tomcat 4 Version: 4.1.16 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Blocker Priority: Other Component: Jasper AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I started with the source code that appeared in the OnJava article http://www.onjava.com/pub/a/onjava/2002/04/03/tomcat.html. I am trying to serve a webapp that works fine when I run Tomcat standalone. When I start the embedded Tomcat, it serves HTML pages just fine. When trying to serve JSPs however, the servlet code is generated, but the compile fails (log at the end of this message, my changes to the source follow that). I suspect that it fails because Ant can't resolve any java files in the work directory, since the compile fails with: Error compiling file: C:\Program Files\Apache Group\Tomcat 4.1\work\_\localhost\texas\/index_jsp.java The log shows: Creating engine Creating host 'localhost' with appBase 'C:/Program Files/Apache Group/Tomcat 4.1/webapps' Creating context '' with docBase 'C:/Program Files/Apache Group/Tomcat 4.1/webapps/ROOT' Creating context '/examples' with docBase 'C:/Program Files/Apache Group/Tomcat 4.1/webapps/examples/jsp' Creating context '/tomcat-docs' with docBase 'C:/Program Files/Apache Group/Tomcat 4.1/webapps/tomcat-docs' Adding engine (org.apache.catalina.core.StandardEngine/1.0) Creating connector for address='ALL' port='80' secure='false' Adding connector (org.apache.coyote.tomcat4.CoyoteConnector2/1.0) Starting embedded server Apache Tomcat/4.1.12 StandardContext[]: Starting StandardContext[]: Processing start(), current available=false StandardContext[]: Configuring default Resources StandardContext[]: Configuring non-privileged default Loader StandardContext[]: Configuring default Manager StandardContext[]: Processing standard container startup WebappLoader[]: Deploying class repositories to work directory C:\Program Files\Apache Group\Tomcat 4.1\work\_\localhost\_ ContextConfig[]: ContextConfig: Processing START StandardContext[]: Setting deployment descriptor public ID to '-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN' StandardContext[]: Setting deployment descriptor public ID to '-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN' ContextConfig[]: Accumulating TLD resource paths ContextConfig[]: Scanning taglib elements in web.xml ContextConfig[]: Scanning TLDs in /WEB-INF subdirectory ContextConfig[]: Scanning JARs in /WEB-INF/lib subdirectory ContextConfig[]: Added certificates - request attribute Valve ContextConfig[]: Pipline Configuration: ContextConfig[]: org.apache.catalina.valves.CertificatesValve/1.0 ContextConfig[]: org.apache.catalina.core.StandardContextValve/1.0 ContextConfig[]: == NamingContextListener[/null/localhost]: Creating JNDI naming context NamingContextListener[/null/localhost]: Resource parameters for UserTransaction = null StandardManager[]: Seeding random number generator class java.security.SecureRandom StandardManager[]: Seeding of random number generator has been completed StandardContext[]: Posting standard context attributes StandardContext[]: Configuring application event listeners StandardContext[]: Sending application start events StandardContext[]: Starting filters StandardWrapper[:default]: Loading container servlet default StandardWrapper[:invoker]: Loading container servlet invoker StandardContext[]: Starting completed 0 [main] INFO http11.Http11Protocol - Initializing Coyote HTTP/1.1 on port 80 61 [main] INFO http11.Http11Protocol - Starting Coyote HTTP/1.1 on port 80 StandardHost[localhost]: Installing web application at context path /texas from URL file://C:/Program Files/Apache Group/Tomcat 4.1/webapps/texas WebappLoader[/texas]: Deploying class repositories to work directory C:\Program Files\Apache Group\Tomcat 4.1\work\_\localhost\texas WebappLoader[/texas]: Deploy class files /WEB-INF/classes to C:\Program Files\Apache Group\Tomcat 4.1\webapps\texas\WEB-INF\classes WebappLoader[/texas]: Deploy JAR /WEB-INF/lib/dom4j.jar to C:\Program Files\Apache Group\Tomcat 4.1\webapps\texas\WEB-INF\lib\dom4j.jar WebappLoader[/texas]: Deploy JAR /WEB-INF/lib/filetags.jar to C:\Program Files\Apache Group\Tomcat 4.1\webapps\texas\WEB-INF\lib\filetags.jar WebappLoader[/texas]: Deploy JAR /WEB-INF/lib/xtags.jar to C:\Program Files\Apache Group\Tomcat 4.1\webapps\texas\WEB-INF\lib\xtags.jar ContextConfig[/texas]: Added
DO NOT REPLY [Bug 15403] - Embedded Tomcat can't compile JSP .java file due to extra /
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15403. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15403 Embedded Tomcat can't compile JSP .java file due to extra / [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID Version|4.1.16 |4.1.17 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Embedded Tomcat and custom connector ?
Hi back That was not so clear. What I would like to do is to get *all* http requests and manage them trough another connector then the one that passes them to the filesystem. Example: a http request comes and it's a GET /Test instead of trying to fetch the local Test directory I want to redirect this to another resource like a sql procedure or something else. I think that it's possible to do this by creating the connector by myself instead of creating it on the high level with createConnector method of the Embedded class. Something like creating a HttpConnector with an associated EventHanlder ? Any tips ? Any idea ? Thanks in advance. Eriam Eriam Schaffter wrote: Hi all. I'm embedding tomcat in a java app using the Embedded class. What I would like to do know is to use the http connector but I would instantiate it by my own and not via the createConnector method so I handle requests and responses in my program. The goal is to have a connector that handles http request a bit differently then the one in tomcat (redirect get request on another resource). Any suggestions ? Eriam -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Embedded Tomcat and ClassLoader's
Hi,
I'd appreciate any thoughts on the following (am I changing Tomcat code in
an acceptable way, or is there another solution like subclassing, etc. to
do what I want?):
I am using the Embedded class to run Tomcat in my Java application
(Eclipse) and need to control the compilation/running of JSP's in a dynamic
way:
all the requests to JSP's go to a dispatcher servlet that creates a class
loader based on the JSP path, sets it on the current Thread context and
redirect to the JspServlet to process the request. Since the Thread context
class loader was set by me, I expect that JspServlet to be run in the same
request thread and use that class loader.
This only works if I make two simple modifications to the Tomcat code, in
ApplicationDispatcher and JspServlet, and I wonder if these change have any
bad side effects:
org.apache.catalina.core.ApplicationDispatcher.invoke() :
-
It looks like the current Tomcat code is chaning the Thread context class
loader to always be the webapp class loader. Can I safely comment out the
following code (and the matching one at the end of the invode() method) ?
Basically, I want that the class loader set on the Thread context to be the
one used, even though it will not be the same as the webapp class loader.
ClassLoader oldCCL = Thread.currentThread().getContextClassLoader
();
ClassLoader contextClassLoader = context.getLoader().getClassLoader
();
if (oldCCL != contextClassLoader) {
Thread.currentThread
().setContextClassLoader(contextClassLoader);
} else {
oldCCL = null;
}
org.apache.jasper.servlet.JspServlet.init() :
The parentClassLoader is set in the constructor
// Get the parent class loader
parentClassLoader =
(URLClassLoader) Thread.currentThread().getContextClassLoader();
if (parentClassLoader == null)
parentClassLoader = (URLClassLoader)this.getClass
().getClassLoader();
but I want to dynamically change it, as I previously mentioned. The simple
solution is to have a getParentClassLoader() method that is basically the
above code, and not use the field this.parentClassLoader. I think this is
safe, but again, are there any potential bad side effects?
Thanks
-Dorian
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Embedded Tomcat and custom connector ?
Hi all. I'm embedding tomcat in a java app using the Embedded class. What I would like to do know is to use the http connector but I would instantiate it by my own and not via the createConnector method so I handle requests and responses in my program. The goal is to have a connector that handles http request a bit differently then the one in tomcat (redirect get request on another resource). Any suggestions ? Eriam -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
embedded tomcat and JspServlet
I've written an Embedded tomcat (4.0.3) that reads in the standard
${catalina.home}/conf/web.xml. Servlets and .war files work fine. However, when I
try to fetch a jsp page, the result comes back with several stack traces to the effect
of not being able to find the javax.servlet package and classes.
The catalina log contains:
jsp: init
Internal Error: File /WEB-INF/web.xml not found.
Any notions?
Thanks,
Rich
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: embedded tomcat and JspServlet
Richard Unger wrote: jsp: init Internal Error: File /WEB-INF/web.xml not found. I believe this particular error message is generated (by o.a.j.compiler.TldLocationsCache.processWebDotXml) when initializing the default context (which doesn't have a WEB-INF/web.xml). I don't think this causes any problems (nor is it the source of your error) and the message should probably be suppressed. Arvind -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Classloader issue with Embedded tomcat and WAR deployment
I figured it out. For the curious, I was specifying a loader for my root context, but that wasn't being propogated to any WAR files, only to servlets explicitly added to the root context at startup time. I had to set the parent classloader on the host which was loading the WAR files. Rich -Original Message- From: Richard Unger Sent: Monday, April 01, 2002 4:36 PM To: '[EMAIL PROTECTED]' Subject: Classloader issue with Embedded tomcat and WAR deployment I'm making a tomcat 4.0.3 module for netbeans, and I'm running into an odd problem with the org.apache.catalina.loader.WebappClassLoader. I'm utilizing the Embedded class to build my server, and I'm using the HostConfig mechanism for rolling in WAR files. I have no trouble loading individual servlets, but when I start the server with a WAR file in place, I get a NoClassDefFoundError: javax/servlet/http/HttpServlet. The error is masked by a catch( Throwable t) clause in HostConfig::deployApps, but when I explicitly print the stack trace, it looks like: java.lang.NoClassDefFoundError: javax/servlet/http/HttpServlet at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:493) at java.security.SecureClassLoader.defineClass(SecureClassLoader. java:111) at org.apache.catalina.loader.WebappClassLoader.findClassInternal (WebappClassLoader.java:1631) at org.apache.catalina.loader.WebappClassLoader.findClass(WebappC lassLoader.java:926) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappC lassLoader.java:1360) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappC lassLoader.java:1243) at org.apache.catalina.core.StandardWrapper.loadServlet(StandardW rapper.java:865) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper. java:808) at org.apache.catalina.core.StandardContext.loadOnStartup(Standar dContext.java:3266) at org.apache.catalina.core.StandardContext.start(StandardContext .java:3395) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase. java:785) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:454) at org.apache.catalina.core.StandardHost.install(StandardHost.java:723) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:331) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:398) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConf ig.java:232) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(L ifecycleSupport.java:156) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1131) at org.apache.catalina.core.StandardHost.start(StandardHost.java:614) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1123) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:343) at org.apache.catalina.startup.Embedded.start(Embedded.java:957) at org.netbeans.modules.httpserver.TomcatServer.start(Unknown Source) at org.netbeans.modules.httpserver.HttpServerModule$1.run(Unknown Source) Delving into StandardWrapper line 865, I see the classloader attempting to load the servlet residing in the WAR file. This servlet extends HttpServlet, and that's where my error is coming from. However, if I stick in a line: classLoader.loadClass(javax.servlet.http.HttpServlet) before line 865, everything works fine. I'm guessing this is because HttpServlet gets loaded in an earlier run of StandardWrapper::loadServlet() (like when the DefaultServlet gets loaded). Must I explicitly set the parent classloader for the org.apache.catalina.loader.WebappLoader? How? Rich -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Classloader issue with Embedded tomcat and WAR deployment
I'm making a tomcat 4.0.3 module for netbeans, and I'm running into an odd problem with the org.apache.catalina.loader.WebappClassLoader. I'm utilizing the Embedded class to build my server, and I'm using the HostConfig mechanism for rolling in WAR files. I have no trouble loading individual servlets, but when I start the server with a WAR file in place, I get a NoClassDefFoundError: javax/servlet/http/HttpServlet. The error is masked by a catch( Throwable t) clause in HostConfig::deployApps, but when I explicitly print the stack trace, it looks like: java.lang.NoClassDefFoundError: javax/servlet/http/HttpServlet at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:493) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:111) at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:1631) at org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:926) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1360) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1243) at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:865) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:808) at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3266) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3395) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:785) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:454) at org.apache.catalina.core.StandardHost.install(StandardHost.java:723) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:331) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:398) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:232) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:156) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1131) at org.apache.catalina.core.StandardHost.start(StandardHost.java:614) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1123) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:343) at org.apache.catalina.startup.Embedded.start(Embedded.java:957) at org.netbeans.modules.httpserver.TomcatServer.start(Unknown Source) at org.netbeans.modules.httpserver.HttpServerModule$1.run(Unknown Source) Delving into StandardWrapper line 865, I see the classloader attempting to load the servlet residing in the WAR file. This servlet extends HttpServlet, and that's where my error is coming from. However, if I stick in a line: classLoader.loadClass(javax.servlet.http.HttpServlet) before line 865, everything works fine. I'm guessing this is because HttpServlet gets loaded in an earlier run of StandardWrapper::loadServlet() (like when the DefaultServlet gets loaded). Must I explicitly set the parent classloader for the org.apache.catalina.loader.WebappLoader? How? Rich -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5345] - Redirection fails in embedded Tomcat in wspack1-b06
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5345. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5345 Redirection fails in embedded Tomcat in wspack1-b06 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2001-12-14 16:29 --- The fix is causing more problems in other area, so the bug is being reopened. Since there is no way that this can be fixed in jasper, I'll let the container handle it. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5345] - Redirection fails in embedded Tomcat in wspack1-b06
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5345. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5345 Redirection fails in embedded Tomcat in wspack1-b06 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2001-12-11 17:32 --- Fixed (nightly build 20011212) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5345] New: - Redirection fails in embedded Tomcat in wspack1-b06
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5345. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5345 Redirection fails in embedded Tomcat in wspack1-b06 Summary: Redirection fails in embedded Tomcat in wspack1-b06 Product: Tomcat 4 Version: Nightly Build Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Major Priority: Other Component: Jasper AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The redirection to another JSp fails in the embedded tomcat in the WSPack 1.0 EA1 -b06 this is the JSP which redirects: Name: Original.jsp %-- test JSP by Prasad --% % String path=Redirected.jsp; % % response.sendRedirect(path); % Pls get redirected !! ** This is the JSP to which the redirection happens: Name: Redirected.jsp %-- test JSP by Prasad --% This is the new JSP ** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5345] - Redirection fails in embedded Tomcat in wspack1-b06
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5345. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5345 Redirection fails in embedded Tomcat in wspack1-b06 --- Additional Comments From [EMAIL PROTECTED] 2001-12-10 12:14 --- Catalina now enforces the spec requrements that the response is closed after a redirect or a sendError. So that's why it now fails. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
