Re: java.lang.NoSuchMethodError
The tag you are writing must have both a getter and a setter for each attribute listed in the TLD file. e.g. if your attribute name is 'size', then your Tag class MUST have the following methods: public int getSize(); public void setSize(int value); Note that the methods follow the bean property naming conventions, so that the 's' in 'size' is lower case in the attribute name, but upper case in the getter and setter method names. This is important. Cheers ------- Aaron Knauf Implementation Consultant Genie Systems Ltd Auckland, New Zealand Ph. +64-9-573 3310 x812, email: [EMAIL PROTECTED] http://www.geniesystems.com Purna Ponguluri <[EMAIL PROTECTED]> 14/03/2001 05:39 Please respond to tomcat-dev To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> cc: Subject: java.lang.NoSuchMethodError Hi, when i am compile the jsp i am getting the following exception.Please tell me the solutionto get rid from this exception. java.lang.NoSuchMethodError at org.apache.jasper.compiler.TagLibraryInfoImpl.createAttribute(TagLibraryInfo Impl.java:524) at org.apache.jasper.compiler.TagLibraryInfoImpl.createTagInfo(TagLibraryInfoIm pl.java:432) at org.apache.jasper.compiler.TagLibraryInfoImpl.parseTLD(TagLibraryInfoImpl.ja va:385) at org.apache.jasper.compiler.TagLibraryInfoImpl.(TagLibraryInfoImpl.java :233) at org.apache.jasper.compiler.JspParseEventListener.handleDirective(JspParseEve ntListener.java:706) at org.apache.jasper.compiler.DelegatingListener.handleDirective(DelegatingList ener.java:116) at org.apache.jasper.compiler.Parser$Directive.accept(Parser.java:215) at org.apache.jasper.compiler.Parser.parse(Parser.java:1077) at org.apache.jasper.compiler.Parser.parse(Parser.java:1042) at org.apache.jasper.compiler.Parser.parse(Parser.java:1038) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:182) at org.apache.jasper.JspC.parseFile(JspC.java:367) at org.apache.jasper.JspC.parseFiles(JspC.java:632) at org.apache.jasper.JspC.main(JspC.java:680) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Tomcat as a Service on NT
Put your zip/jar files in the WEB-INF/lib directory. Aaron Knauf Systems Integrator Genie Systems Ltd Auckland, New Zealand Ph. +64-9-573 3310 x812 email: [EMAIL PROTECTED] http://www.geniesystems.com "Hodgert, William H" <[EMAIL PROTECTED]> 07/11/2000 06:15 Please respond to tomcat-dev To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>, "'[EMAIL PROTECTED]%INTERNET'" <[EMAIL PROTECTED]>, "'[EMAIL PROTECTED]%INTERNET'" <[EMAIL PROTECTED]> cc: "'[EMAIL PROTECTED]%INTERNET'" <[EMAIL PROTECTED]> Subject: RE: Tomcat as a Service on NT Anthony, The NT service does not use the tomcat.bat file. The wrapper.properties has a wrapper.class_path variable that you can add you classes111.zip into. Heath -Original Message- From: Miller, Anthony [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 02, 2000 12:15 AM To: '[EMAIL PROTECTED]%INTERNET'; '[EMAIL PROTECTED]%INTERNET'; '[EMAIL PROTECTED]%INTERNET' Cc: '[EMAIL PROTECTED]%INTERNET' Subject: Tomcat as a Service on NT Hi, I have installed Tomcat as a service on NT but now it can't see the classes111. zip file for the oracle driver. I've tried adding set CLASSPATH=%CLASSPATH% to the tomcat.bat file (instead of set CLASSPATH=. etc) but it can't see the classes111.zip file. However when I run the service in debug (tomcatsvc -debug) on the command line its fine!!. Can anybody give me some pointers to how I might solve this jolly annoying problem Anthony - Anthony S. Miller B.Sc. M.Sc. AMIEE Software Engineer BAE SYSTEMS Grange Road Christchurch Dorset BH23 4JE --- Tel +44 (0)1202 404725 Fax +44 (0)1202 408335 mailto:[EMAIL PROTECTED] - 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]
A HOWTO document for making HTTPS connections from servlets hosted bytomcat
I have written an in-house howto for configuring Tomcat to support SSL/HTTPS connections made by servlets. I have obtained permission to give the document to the tomcat project community. I am placing the document under the APL. No liability is accepted for any damages incurred through the use of this document. By following the procedure in this document, I have successfully configured a (fairly simple) servlet that I wrote to use HTTPS instead of HTTP without changing a single line of code. I figured that others might also find that useful. If you find the document useful - great. If you find any errors - fix them. If you make any improvements, it would be good if you could drop me a copy of the updated document. Cheers Aaron Knauf Systems Integrator Genie Systems Ltd Auckland, New Zealand Ph. +64-9-573 3310 x812 email: [EMAIL PROTECTED] http://www.geniesystems.com HTTPS Configuration Howto for Servlets under Tomcat. Author - Aaron Knauf, Genie Systems Ltd ([EMAIL PROTECTED]) Date- 20001107 Version - 0.1 Abstract This document explains how to install and configure the Sun Java Secure Sockets Extension so that servlets can make HTTPS calls under the Jakarta Tomcat servlet engine. This Howto is based on version 1.0.2 of the JSSE. Other versions may or may not work. Introduction When making HTTPS calls to servlets hosted by Tomcat, no Tomcat-specific configuration or functionality is necessary if Tomcat is configured to integrate with a web-server such as IIS or Apache. The web server supplies the necessary SSL communications functionality. In order for servlets to be aware of the SSL communication, Tomcat 3.2 or better must be used, with the Apache Java Protocol 1.3 or better for connection to the web server. Without these versions, details of certificate properties and other SSL/HTTPS specific information is not available to the servlet. Note that as of Tomcat release 3.2, the Jakarta Isapi Redirector supports only AJP1.2. In order for servlets themselves to initiate HTTPS/SSL encrypted connections, the the Sun JSSE extension must be installed as a 'java installed extension'. Although it is possible for the servlet to bundle this extension, this requires more complex configuration of Tomcat itself and is considered (by me) to be an inferior solution. This document covers installation and configuration of the JSSE as a java installed extension so that servlets can initiate HTTPS/SSL connections. JSSE Installation After downloading the JSSE, extract the three jar files (jcert.jar, jnet.jar and jsse.jar) from the archive and place them in the /lib/ext directory. Edit the /lib/security/java.security file and locate the following section: # # List of providers and their preference orders (see above): # security.provider.1=sun.security.provider.Sun security.provider.2=com.sun.rsajca.Provider Edit the section to include a third security provider line, as follows: # # List of providers and their preference orders (see above): # security.provider.1=sun.security.provider.Sun security.provider.2=com.sun.rsajca.Provider security.provider.3=com.sun.net.ssl.internal.ssl.Provider Tomcat Configuration The following modification must be made to the tomcat startup file. (This assumes that tomcat is configured to run as a service.) Edit the /conf/wrapper.properties and locate the following line (which should be located at the end of the file): wrapper.cmd_line=$(wrapper.javabin) -classpath $(wrapper.class_path) $(wrapper.startup_class) -config $(wrapper.server_xml) -home $(wrapper.tomcat_home) Edit this line to say the following: wrapper.cmd_line=$(wrapper.javabin) -Djava.protocol.handler.pkgs=com.sun.net.ssl.internal.www.protocol -classpath $(wrapper.class_path) $(wrapper.startup_class) -config $(wrapper.server_xml) -home $(wrapper.tomcat_home) (Note that this should all appear on one line. The line is wrapped here for readability.) Restart the tomcat service. A Note On Servlet Coding In order for a servlet to make an HTTPS connection to a web server, it must use a java.net.URL object. The URL object attempts to load a URLConnection based on th
Re: [TC4] multiple certificates
I believe that the different port idea is correct (for any web server - not just tomcat). Another point to consider is that if tomcat is used in conjunction with a web server (such as apache or IIS), the web server does all of the SSL stuff for the communication with the browser, so you are stuck with web server limitations that are out of tomcat's control. Aaron Knauf Systems Integrator Genie Systems Ltd Auckland, New Zealand Ph. +64-9-573 3310 x812 email: [EMAIL PROTECTED] http://www.geniesystems.com "Warner Onstine" <[EMAIL PROTECTED]> 22/11/2000 18:36 Please respond to tomcat-dev To: <[EMAIL PROTECTED]> cc: Subject: Re: [TC4] multiple certificates - Original Message - From: "Craig R. McClanahan" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, November 21, 2000 7:43 PM Subject: Re: [TC4] multiple certificates > Warner Onstine wrote: > > > Hi all, > > It's been a while since I looked at the SSL stuff and I just received a > > request which I'm not sure how it would be handled in TC4. Would it be > > possible to handle multiple certificates for SSL per servlet? If this needs > > further clarification let me know. > > > > I guess I don't quite get what you are after. > > Are you talking about a certificate chain that authenticates an individual > user? If so, that is already supported -- the request attribute that you get is > an array of certificate objects, with the first one being the certificate of the > client principal, and the subsequent ones being the certificates of the > certificate authorities vouching for the previous certificate in the chain. Sure, what we're working with is possibly using different server certificates for different servlets, is this at all possible? From what I can tell right now, no. Basically what I see right now is if we turn on ssl support it uses the certificate that you specify for each connection from the SSLServerSocketFactory. The only way I can see doing this is to specify a different port for different certificates, correct? > If that's not what you are after, could you please explain further? > > > Craig Thanks, -warner
JSSE redistribution
Is there any reason why we can't compile tomcat against JSSE and include the jars in the tomcat lib directory as part of the standard binary distribution? This would make it much easier for people to get HTTPS support from tomcat. I believe that the Sun licence allows for redistribution, and US law allows us foreigners to get at the crypto stuff, now. I seem to remember seeing a post about this a while ago, but I never saw a resolution. If there are no objections, I move that we include JSSE as part of standard tomcat. Cheers --- Aaron Knauf Implementation Consultant Genie Systems Ltd Auckland, New Zealand Ph. +64-9-573 3310 x812, email: [EMAIL PROTECTED] http://www.geniesystems.com
Re: JSSE redistribution
Ain't crypto laws a bitch? I see your point. I withdraw my suggestion. Cheers --- Aaron Knauf Implementation Consultant Genie Systems Ltd Auckland, New Zealand Ph. +64-9-573 3310 x812, email: [EMAIL PROTECTED] http://www.geniesystems.com "Craig R. McClanahan" <[EMAIL PROTECTED]> 13/12/2000 15:21 Please respond to tomcat-dev To: [EMAIL PROTECTED] cc: Subject: Re: JSSE redistribution Aaron Knauf wrote: > > Is there any reason why we can't compile tomcat against JSSE and include the > jars in the tomcat lib directory as part of the standard binary distribution? > This would make it much easier for people to get HTTPS support from tomcat. I > believe that the Sun licence allows for redistribution, and US law allows us > foreigners to get at the crypto stuff, now. > Although the rules have been relaxed considerably, the US export regulations still require preventing anyone from certain countries from downloading this stuff. If JSSE was distributed in Tomcat, that would mean that we (Apache) would be held responsible for enforcing that restriction -- and this would most likely require some sort of click-through mechanism on *everyone* who downloads (plus a bunch of lawyer time to make sure all the rules were being followed). There is also still paperwork involved in registering as a distributor of encryption materials -- even though it's legal. > > I seem to remember seeing a post about this a while ago, but I never saw a > resolution. > > If there are no objections, I move that we include JSSE as part of standard > tomcat. > Given that the restriction above exists, I'm afraid I can't see us doing this at the current time. > > Cheers > Craig McClanahan
Re: F....
I have been following this insane tomcat 4 vs tomcat 3 debate with increasing amazement. I cannot understand why this has become such a big issue. Attempting to tell an open source developer what to write is pretty much counter to ESR's cited prime motivation for open source development - scratching a personal itch! If Costin (bless his soul) wants to make TC3 a better product, then he has my own profound thanks! As a user of tomcat (I use tomcat every day as part of my job) am very keen to see tomcat 3.x development continue as long as tomcat 4 falls short of release quality. Until IIS integration and SSL client certificate support are considered release quality in tomcat 4, I am keen to see them developed on tomcat 3. In fact, I believe that the time to abandon tomcat 3 development will come at around the point that new features are able to reach release quality as fast on tomcat 4 as on tomcat 3. The technology used in tomcat 3 is perfectly current. Forcing people into participating in development of a bleeding edge product in order to add features to tomcat seems pretty mercurial. Tomcat 3 is just becoming a premium quality product. There are two or three features still to be added to completely satisfy my own requirements of a servlet container. If we abandon development now in favour tomcat 4, tomcat will remain a bleeding edge product and may never reach the mainstream release quality that I for one would like to see. What I suggest is this: Whoever wants to develop on tomcat 4 does so. Whoever wants to develop on tomcat 3 does so. Versions are managed in a similar manner to the linux development/stable trees, with code from TC4 merged back into TC3 whenever the TC3 guys feels that this enhances the product. (And no complaining about the tomcat 3 guys 'copying' the TC4 guys - that is kind of the point of open source!) Cheers and Merry Christmas! ------- Aaron Knauf Implementation Consultant Genie Systems Ltd Auckland, New Zealand Ph. +64-9-573 3310 x812, email: [EMAIL PROTECTED] http://www.geniesystems.com Jon Stevens <[EMAIL PROTECTED]> 22/12/2000 11:26 Please respond to tomcat-dev To: <[EMAIL PROTECTED]> cc: Subject: Re: F on 12/21/2000 2:18 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > Tomcat3.2 is a big step forward versus Tomcat3.1 - but it still have many > issues - take a look at the ContextManager in 3.3, compare it with 3.2 - > there are still many undefined behaviors, even code from 3.0. Tomcat 3.2 has *only* happened because Tomcat 4.0 wasn't ready. Remember the history of Tomcat 4.0 and the fact that if Sun didn't donate a bunch of cruft software, we would have spent the time working on JServ 2.0 which is now what Tomcat 4.0 is. The fact of the matter is that because we had to deal with 3.x and support improving it that delayed the development of 4.0 to not being ready until now. It is this duplication of effort that needs to stop. We need to quit sitting back and trying to support something that should have been dead long ago. -jon
Re: An important question
Please don't start that again. --- Aaron Knauf Implementation Consultant Genie Systems Ltd Auckland, New Zealand Ph. +64-9-573 3310 x812, email: [EMAIL PROTECTED] http://www.geniesystems.com Jon Stevens <[EMAIL PROTECTED]> 28/12/2000 08:27 Please respond to tomcat-dev To: <[EMAIL PROTECTED]> cc: Subject: Re: An important question on 12/27/2000 11:20 AM, "David Lavigne" <[EMAIL PROTECTED]> wrote: > How can the future of Tomcat be 4.0 while it does not have connectors to > the web servers that 3.x have? I believe that it will be the future as > soon as these exist, otherwise there is no point in making Tomcat a > separate product from Apache httpd when that is the only webserver Catalina > supports. Maybe if we hadn't been focusing so hard on 3.x, then 4.0 would have had those features. *That* is the point. -jon
Re: Authorization on Linux
I would go one further and advise against using the system user accounts for web user authentication. Even if you are using SSL to encrypt traffic, it is easy to brute force a web password because the web server typically allows unlimited retries without locking the account, or delaying and in some configurations may not even log the attempts. Another advantage to using an alternative user accounts database is that you don't have to give every web user access to all of the other facilities on your web server. (If the user account doesn't exist, no-one can log in with it.) Apache provides modules for authenticating against all sorts of other user accounts. Perhaps you could try to hook in to one of these. ------- Aaron Knauf Implementation Consultant Genie Systems Ltd Auckland, New Zealand Ph. +64-9-573 3310 x812, email: [EMAIL PROTECTED] http://www.geniesystems.com "Craig R. McClanahan" <[EMAIL PROTECTED]> 03/01/2001 11:08 Please respond to tomcat-dev To: [EMAIL PROTECTED], [EMAIL PROTECTED] cc: Subject: Re: Authorization on Linux Mikael Pahmp wrote: > I'm using Tomcat with Apache on a RedHat 6.2 Linux. I use the form-based login mechanism and want to authorize the user logins against the users/groups that are already defined in Linux. It seems to be possible by implementing an Interceptor. It is certainily feasible to do this with a request interceptor (Tomcat 3.x) or valve (Tomcat 4.x). You would need to provide a custom implementation (you can use the existing JDBCRealm implementation as a model) and configure Tomcat to use it in the server.xml file. One very important thing you should consider before doing so, however, is the way that usernames and passwords get communicated when using HTTP authentication methods. If you use BASIC or FORM-BASED authentication, your username and password are essentially passed as clear-text. Therefore, if I can snoop the network connection, I can now attack your server with a known-good username and password -- *not* something you really want to have happen. Moral of the story -- if you are in an environment where your network connections are subject to snooping, use SSL, or DIGEST-mode authentication. This is a good general principle even if your usernames and passwords relate only to the webapp you are running, but are even more important when exposure could increase security risks on your entire server. > > Has anyone already done this and is willing to share his work? > > Otherwise, tips for how to do it is appreciated. > > /Mikael > Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
IIS/ISAPI connection to tomcat
I have a little problem with the isapi_redirect.dll connector to Tomcat. There seems to be a buffering problem with sending the response back to the browser. My symptoms are as follows: I access a JSP file running in Tomcat via the IIS and isapi_redirect.dll and I receive a page back that has random fragments of HTML repeated several times. I am happy with tracking down the problem and fixing it myself, if necessary, but before I do that I would like to ensure that I am not wasting my time. I am using tomcat 3.1-FINAL and a version of isapi_redirect.dll of about the same vintage. I cannot upgrade this server to Tomcat 3.2, as the case sensitivity breaks existing code (not written by me - bloody IIS). Has anyone seen/fixed this problem before? I see that there have been some changes to the source files since then. Should I be using a later version of the redirector, or is the new code specific to a later tomcat version? (I don't want to be fixing old code.) Thanks in advance for any help/advice that you can offer. --- Aaron Knauf Implementation Consultant Genie Systems Ltd Auckland, New Zealand Ph. +64-9-573 3310 x812, email: [EMAIL PROTECTED] http://www.geniesystems.com
Re: [ANNOUNCEMENT] Tomcat 4.0-beta-7 Released
I am submitting a bug report here, as jakarta.apache.org is reporting "connection refused". A bug in Tomcat 4.0-beta-7: DTD URL for the webapp 2.3 dtd is now incorrect. "http://java.sun.com/j2ee/dtds/web-app_2_3.dtd"; is a file containing the following message: --- The file named http://java.sun.com/j2ee/dtds/web-app_2_3.dtd has been renamed to http://java.sun.com/dtd/web-app_2_3.dtd in the most current version of the specification. Please update your application to use the new name. --- One more note: Now that the XML parser used to parse the web.xml and tld files is (correctly) strict about element order, it would be handy if the filename were displayed along with the parser error messages. (So I can find all the error in my incorrectly ordered deployment descriptors and tld files!) Cheers --- Aaron Knauf Software Developer Genie Systems Ltd Auckland, New Zealand Ph. +64-9-573 3310 x812, email: [EMAIL PROTECTED] http://www.geniesystems.com "Pier P. Fumagalli" <[EMAIL PROTECTED]> 11/08/2001 16:01 To: <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> cc: Subject:Re: [ANNOUNCEMENT] Tomcat 4.0-beta-7 Released Pier P. Fumagalli at [EMAIL PROTECTED] wrote: > Craig R. McClanahan at [EMAIL PROTECTED] wrote: > >> [...] >> In addition, as with the previous version, an installer-based version of >> Tomcat 4.0-beta-7 is available for Windows users, as well as native code >> versions of the mod_webapp connector for Apache. > > Binary distributions for the WebApp connector are available at: > > <http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0-b7/bin> Also for Win32 (since MANY people asked!). Those CAN NOT be built from the same sources distribution as the build process for windows was added AFTER 4.0b7 was released, but are built on top of the same sources. To build the WebApp module on your own, check out the CVS version. Pier
