Re: [OT] SecurityManager and Java Policy Files
2010/3/25 Christopher Schultz : I will try to be brief in my answers below, so please excuse some apparent harshness. >(...) > In the Tomcat SecurityManager docs > (http://tomcat.apache.org/tomcat-6.0-doc/security-manager-howto.html), > most of the "grants" in the policy file do not have a codeBase. Why are you looking there? The policy file cited there is "conf/catalina.policy". I would prefer the live copy over the paper. (Though the doc should match the file). > most of the What you mean by "most"? Are you counting "AllPermission" as "one" versus all those in the "by default" grant block as "many"? > By the way, I /have/ read > http://java.sun.com/j2se/1.5.0/docs/guide/security/PolicyFiles.html but > some things are still unclear. Java 6 docs are below from here: http://java.sun.com/javase/6/docs/technotes/guides/security/index.html See also the following document there http://java.sun.com/javase/6/docs/technotes/guides/security/spec/security-spec.doc.html http://java.sun.com/javase/6/docs/technotes/guides/security/spec/security-specTOC.fm.html > it appears that the SecurityManager is enforcing > permissions along with the call chain... It is documented in those specifications by Sun. It looks the call chain up to the nearest AccessController.doPrivileged(). http://java.sun.com/javase/6/docs/technotes/guides/security/spec/security-spec.doc4.html#24646 http://java.sun.com/javase/6/docs/api/java/security/AccessController.html > Third: doesn't this make performance really suck? As with any performance question: test it yourself and for your own application/environment. Only that will give you numbers. It may be that impact of those "security checks" is small compared to other bottlenecks in one's application. Though, personally, I do not like when a computer performs "useless" work. > such as granting AllPermission to things like bootstrap.jar That is determined by the task that this protection performs. In general, the idea is that what is installed by "administrator" is controlled and thus trusted, but the web applications themselves are not trusted by default. Also if the web applications are not trusted, it would make sense to limit their control over Tomcat settings, by setting deployXML="false" on a . By the way, Mark's presentations from recent ApacheCons are here: http://people.apache.org/~markt/presentations/ Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Problems with ImageIO custom service providers with Tomcat >= 6.0.24
On 30/03/2010 00:21, Simone Giannecchini wrote: > Ciao, > long story short, in an OS geospatial project that we maintain we are > experiencing problems when deploying on Tomcat >= 6.0.24 due to the > latest permgen fixes ( I guess). Define problems. What? When? > It looks like that ImageIO additional service providers are not loaded > anymore at runtime via the standard jar META-INF/services mechanism. > Any hints for putting together a workaround? How about some hints on what problem you are seeing. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Problems with ImageIO custom service providers with Tomcat >= 6.0.24
Ciao, long story short, in an OS geospatial project that we maintain we are experiencing problems when deploying on Tomcat >= 6.0.24 due to the latest permgen fixes ( I guess). It looks like that ImageIO additional service providers are not loaded anymore at runtime via the standard jar META-INF/services mechanism. Any hints for putting together a workaround? Ciao, Simone. --- Ing. Simone Giannecchini GeoSolutions S.A.S. Founder - Software Engineer Via Carignoni 51 55041 Camaiore (LU) Italy phone: +39 0584983027 fax: +39 0584983027 mob:+39 333 8128928 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.linkedin.com/in/simonegiannecchini http://twitter.com/simogeo --- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Connecting to a Database
>>If I set the DataSourceRealm in my context.xml file of my >>webapps/webappfldr/META-INF/ will it not allow for a later reference >>separately in the Tomcat manager app? Barry, I thought having a context.xml in META-INF/ was the most specific place to define a context for a webapp, in the heirarchy of Context element locations. http://tomcat.apache.org/tomcat-6.0-doc/config/context.html I have the manager webapp running. In various places in server.xml, other than adding digest, this is the standard tomcat config: In webapps/manager/META-INF/context.xml: -Original Message- From: Propes, Barry L [mailto:barry.l.pro...@citi.com] Sent: Monday, March 29, 2010 2:41 PM To: 'Tomcat Users List' Subject: RE: Connecting to a Database And after doing this, and getting my DataSourceRealm to work properly, now I can't get the Tomcat manager app to work properly now...it references my JNDI realm reference (DataSourceRealm actually) and throws an exception. Even if I delete it out of my context.xml file (the reference) and delete the one created in the conf folder, it still tries to reference the DataSourceRealm credentials and throws an error. If I set the DataSourceRealm in my context.xml file of my webapps/webappfldr/META-INF/ will it not allow for a later reference separately in the Tomcat manager app? Reference to the tomcat-users.xml file? I'll dump out the work folder, too, but it'd be nice to have both working concurrently. I would have thought they would, but am likely mistaken. -Original Message- From: Leo Donahue - PLANDEVX [mailto:leodona...@mail.maricopa.gov] Sent: Friday, March 26, 2010 6:09 PM To: 'Tomcat Users List' Subject: RE: Connecting to a Database You are correct. I stumbled across that info while reading the config in the DataSource Database Realm section but I wasn't looking for that when I saw it the first n times. I was looking for info about the userRoleTable. -Original Message- From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] Sent: Friday, March 26, 2010 2:56 PM To: Tomcat Users List Subject: RE: Connecting to a Database > From: Propes, Barry L [mailto:barry.l.pro...@citi.com] > Subject: RE: Connecting to a Database > > Thanks, Leo! I've not seen instructions in the How-To (maybe I > overlooked it) on the localDataSource="true" attrib to the Realm in > the context.xml file Unfortunately, it's not in the How-To, just in the configuration doc for (which is linked to from the How-To): http://tomcat.apache.org/tomcat-6.0-doc/config/realm.html The How-To is oriented towards server-wide authentication, so the examples all show use of a in server.xml and a corresponding global resource declaration. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Connecting to a Database
> From: Propes, Barry L [mailto:barry.l.pro...@citi.com] > Subject: RE: Connecting to a Database > > And after doing this Doing which? > now I can't get the Tomcat manager app to work properly now...it > references my JNDI realm reference (DataSourceRealm actually) and > throws an exception. Where is the for the manager app defined? Where is the for your webapp defined? > Reference to the tomcat-users.xml file? This sentence no verb. > I'll dump out the work folder, too, but it'd be nice to > have both working concurrently. I would have thought they > would, but am likely mistaken. Did you remove the in server.xml? (You shouldn't, if you want the manager app to use it.) Have you made any changes to the global conf/context.xml? Post your server.xml so we can see it. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Connecting to a Database
And after doing this, and getting my DataSourceRealm to work properly, now I can't get the Tomcat manager app to work properly now...it references my JNDI realm reference (DataSourceRealm actually) and throws an exception. Even if I delete it out of my context.xml file (the reference) and delete the one created in the conf folder, it still tries to reference the DataSourceRealm credentials and throws an error. If I set the DataSourceRealm in my context.xml file of my webapps/webappfldr/META-INF/ will it not allow for a later reference separately in the Tomcat manager app? Reference to the tomcat-users.xml file? I'll dump out the work folder, too, but it'd be nice to have both working concurrently. I would have thought they would, but am likely mistaken. -Original Message- From: Leo Donahue - PLANDEVX [mailto:leodona...@mail.maricopa.gov] Sent: Friday, March 26, 2010 6:09 PM To: 'Tomcat Users List' Subject: RE: Connecting to a Database You are correct. I stumbled across that info while reading the config in the DataSource Database Realm section but I wasn't looking for that when I saw it the first n times. I was looking for info about the userRoleTable. -Original Message- From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] Sent: Friday, March 26, 2010 2:56 PM To: Tomcat Users List Subject: RE: Connecting to a Database > From: Propes, Barry L [mailto:barry.l.pro...@citi.com] > Subject: RE: Connecting to a Database > > Thanks, Leo! I've not seen instructions in the How-To (maybe I > overlooked it) on the localDataSource="true" attrib to the Realm in > the context.xml file Unfortunately, it's not in the How-To, just in the configuration doc for (which is linked to from the How-To): http://tomcat.apache.org/tomcat-6.0-doc/config/realm.html The How-To is oriented towards server-wide authentication, so the examples all show use of a in server.xml and a corresponding global resource declaration. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [OT] SecurityManager and Java Policy Files
Hi, Chris- I don't remember the question exactly but in my experience I've had to grant permissions to all relevant jars that are not within a webapp and to the webapp. (Hopefully, this is at least in the right ballpark for your question.) -Terence Subject: RE: [OT] SecurityManager and Java Policy Files From: "Caldarale, Charles R" Date: Mon, 29 Mar 2010 09:08:39 -0500 To: Tomcat Users List To: Tomcat Users List From: Christopher Schultz [mailto:ch...@christopherschultz.net] Subject: Re: [OT] SecurityManager and Java Policy Files Anyone? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Solved: access to localhost:8080 fails
Hello Harry, You are right. When i took the issue to our IT, they asked me to run a script on my comp that solved the problem. This script has probably tweaked the firewall to allow localhost to run. Feeling good that the problem stands solved that I can continue with my work now but the magic will remain unknow to me. Kind Regards, Krish On Mon, Mar 29, 2010 at 7:02 AM, Harry Metske wrote: > I have seen similar issues on our corporate (XP and Vista) laptops, > somebody > decided that the locally running firewall should also block access to > localhost. I think you should first verify if that's the case. > I'm not a Windows expert, so I don't know how to check if the above is the > case. > If you are allowed to give the netstat command, try the suggestion from > Charles (netstat -ano), if you see status SYN_SENT, it's for sure a > firewall > issue. > > regards, > Harry > > 2010/3/28 Krishanu Biswas > > > Chuck: > > > > To verify the network issue, I installed Tomcat on my personal laptop. > The > > browser is still unable to show up: http//localhost:8080. > > I'm connected to a router via a wireless network which in turn connects > me > > to the internet. I have Mcafee antivirus, firewall and spyware installed. > > > > I will now look into the problem from this direction as well. Thank you. > > > > Krish > > > > On Sun, Mar 28, 2010 at 8:28 PM, Caldarale, Charles R < > > chuck.caldar...@unisys.com> wrote: > > > > > > From: Krishanu Biswas [mailto:biswas.krish...@googlemail.com] > > > > Subject: access to localhost:8080 fails > > > > > > > > I've a 6.0.26 (latest) Tomcat installed on my laptop (windows vista > > > > ulltimate). When inside corporate network, it works. In home network, > > > > it doesn't. > > > > > > Sounds like whatever security agent you're using imposes different > > firewall > > > rules depending on whether or not you're attached to the corporate > > network. > > > (The one we use - SEP - certainly does.) You'll have to figure out > how > > to > > > change the firewall config - if you're allowed to. > > > > > > - Chuck > > > > > > > > > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE > PROPRIETARY > > > MATERIAL and is thus for use only by the intended recipient. If you > > received > > > this in error, please contact the sender and delete the e-mail and its > > > attachments from all computers. > > > > > > > > > - > > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > > > > >
getOutputStream() has already been called for this response
Hello
When I include a servlet inside a tagfile then it works:
But if a try to do the same in a tag that subclasses SimpleTagSupport
then tomcat throws the exception mentioned in the subject:
@Override
public void doTag() throws IOException, JspException {
HttpServletRequest request = (HttpServletRequest) ((PageContext) this
.getJspContext()).getRequest();
HttpServletResponse response = (HttpServletResponse) ((PageContext) this
.getJspContext()).getResponse();
RequestDispatcher requestDispatcher = request
.getRequestDispatcher("/controller");
try {
requestDispatcher.include(request, response);
}
catch (ServletException e) {
throw new JspException("Failed to include action", e);
}
}
Why does tomcat not react the same on these?
Btw. Im trying to invoke a controller in the middle of a JSP rather
than before the JSP because I want to
do component-level MVC instead of page-level MVC.
Full stacktrace is here:
exception
org.apache.jasper.JasperException: java.lang.IllegalStateException:
getOutputStream() has already been called for this response
org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:515)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:405)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:322)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:249)
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
root cause
java.lang.IllegalStateException: getOutputStream() has already been
called for this response
org.apache.catalina.connector.Response.getWriter(Response.java:619)
org.apache.catalina.connector.ResponseFacade.getWriter(ResponseFacade.java:198)
org.apache.jasper.runtime.JspWriterImpl.initOut(JspWriterImpl.java:125)
org.apache.jasper.runtime.JspWriterImpl.flushBuffer(JspWriterImpl.java:118)
org.apache.jasper.runtime.PageContextImpl.release(PageContextImpl.java:188)
org.apache.jasper.runtime.JspFactoryImpl.internalReleasePageContext(JspFactoryImpl.java:118)
org.apache.jasper.runtime.JspFactoryImpl.releasePageContext(JspFactoryImpl.java:77)
org.apache.jsp.index_jsp._jspService(index_jsp.java:99)
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:369)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:322)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:249)
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
Its a tomcat 5.5 i believe embedded in jboss 5.1.0ga.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6 - slow response times outside of data center
Hi Chuck, Thank you very much for chiming in! (Your contributions over the years, along with the other regulars, are the backbone of the list!). Tracert/ping/pathping all give the impression of a well performing network, with response times < 1ms being typical between the various nodes. Looking at how things have been done in this case, the only context.xml is in tomcat/conf -- when taking out commented out sections, context.xml is basically empty. Similarly in this case, I find conf/catalina/* to be an empty hierarchy of folders. The docBases they've specified are intended to be home to (uploadable) static content -- a task I seem to recall being better performed outside of tomcat, although it's been a while since I've traveled that path. For the tests I've mentioned, there shouldn't be I admit I haven't had much time at all to dig into Tomcat's best practices in order to be able to make appropriate recommendations -- although I'm a generalist, I find that the bulk of my time is spent assessing problematic db configurations and making recommendations. I'll try to find extra time to dig into Tomcat via the online docs, wiki, and the O'Reilly book I picked up ages ago (mistakenly thinking I'd have time to read it ;). Aside from those, are there any key resources in particular you'd recommend, in order to hit the ground running in the shortest time possible? In the mean-time, I appreciate any help that's offered...(and have to ask: do you hire yourself out as a consultant, or can you recommend anyone who does?) On Mon, Mar 29, 2010 at 11:11 AM, Caldarale, Charles R < chuck.caldar...@unisys.com> wrote: > > From: Ian Hubbard [mailto:sum.of.pri...@gmail.com] > > Subject: Re: Tomcat 6 - slow response times outside of data center > > > > To try to cut down on the number of variables, on the client machine > > I've tested both with and without hosts file entries. > > Have you tried a simple tracert to and from each machine to see how the > network responds? > > > > caseSensitive="false"> > > > > > docBase="\\servername\data\iimage" > > reloadable="false" caseSensitive="false"> > > > > > docBase="\\servername\data\audio" > > reloadable="false" caseSensitive="false"> > > > > > docBase="\\servername\data\custom" > > reloadable="true" caseSensitive="false"> > > > > The above is really, really bad practice. Having elements in > server.xml is strongly discouraged; they should be in either each webapp's > META-INF/context.xml file, or in conf/Catalina/[host]/[appName].xml when the > webapp is located outside of the 's appBase directory. Also, using a > remote docBase may well be contributing to the sluggishness - best to keep a > copy of the webapp on the server that's running it. Windows networking > produces some really behavior on occasion. > > > > reloadable="false" > > caseSensitive="false"> > > > > That one got you double-deployment; again, don't put elements in > server.xml. > > > > docBase="@datastore.path.root_train...@\iimage" reloadable="false" > > caseSensitive="false"> > > > > > docBase="@datastore.path.root_train...@\audio" reloadable="false" > > caseSensitive="false"> > > > > > docBase="@datastore.path.root_train...@\custom" reloadable="true" > > caseSensitive="false"> > > > > I have no idea what the above docBase references do... > > - Chuck > > > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY > MATERIAL and is thus for use only by the intended recipient. If you received > this in error, please contact the sender and delete the e-mail and its > attachments from all computers. > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Proposal : port mod_expires in java as ExpiresFilter Servlet Filter
Thanks for your fast feedbacks Christopher,
I updated the patch proposed on Bugzilla 48998 to include your advice
to limit the number of null checks. The implementation I found is
slightly different than your proposal but the idea remain the same.
Please note that I only modified the patch and not yet
ExpiresFilter.java on the google-code project as my priority is the
Tomcat proposal.
Regarding the simplification of generating expiration headers just
after 'response.setContentType()' is called rather than after the
first write in the response body, I didn't follow this way because
applications could add/set 'Cache-Control' and/or 'Expires' header
after invoking 'response.setContentType()'.
My understanding is that the filter must work after
'setContentType()', 'set/addHeader("Cache-Control", ...)' and
'set/addHeader("Expires", ...)' have been called but we don't know
which ones will be called and in which order they will be called.
This is the reason why I unfortunately added the complexity to trap
the 'onStartWriteResponseBody' event.
Cyrille
On Mon, Mar 29, 2010 at 3:20 PM, Christopher Schultz
wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Cyrille,
>
> On 3/26/2010 12:43 PM, Cyrille Le Clerc wrote:
> > I have proposed with bugzilla 48998 a port of Apache mod_expires in
> > Java as ExpiresFilter Servlet Filter.
>
> Cool.
>
> > I detailed a standalone version of this filter on
> > http://code.google.com/p/xebia-france/wiki/ExpiresFilter . Moreover, I
> > tried my best to provide very detailed javadocs and docs (in filter.html).
> >
> > The proposed contribution is slightly different than the standalone
> > one because it uses Tomcat logging, few Servlet 3 enhancements and
> > Tomcat engine in the test cases.
>
> I read-through your code on code.google.com and I can see a couple areas
> where I think improvements might be made:
>
> - - In getExpirationDate, you check for the local 'configuration' being
> null several times in a row. In each case, the configuration may be set
> given a different 'level' of configuration. If the configuration gets
> set, several checks must still be made to see if it is null. You could
> mail out early and avoid some of these checks like this:
>
> if(configuration == null) {
> configuration = ...;
>
> if(configuration == null) {
> // try another strategy
> configuration = ...;
>
> if(configuration == null) {
> ...
> }
> }
> }
>
> I think can save a bit of CPU time without much in the way of code
> complexity.
>
> - - You might be able to wrap the Response class and check for the setting
> of the Content-Type header, instead of wrapping the response in order to
> intercept the first buffer flush to the client. Do you think that would
> work? It certainly would remove a lot of complexity from your code.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkuwqQwACgkQ9CaO5/Lv0PDdwgCgrSHwmgUTDWybmk6/G1+AqNzY
> kCQAn0zVrQBARihaoQkfBJRtKYkjvsjs
> =kBWG
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat PUT not working
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael, On 3/28/2010 6:28 PM, Michael Wojcik wrote: > André Warnier wrote: >> For all these reasons, currently Tomcat does not support the >> getParameters() family of methods, when the request method is PUT. > > This is a Tomcat limitation, not an HTTP one. It's not a conformance > issue, because RFC 2616 doesn't require the server do anything in > particular with the query-string. But it does permit a query-string in > a PUT Request-URI. Again, Tomcat does not limit the developer in any way: Tomcat provides access to the "GET parameters" using the getParameter family of methods. It's just that Tomcat will not auto-parse any application/x-www-form-urlencoded request body and integrate the parameters into those coming from the URL. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuw7pUACgkQ9CaO5/Lv0PBDgACgm8ilpdPDDW58O3ZcEVAf1XCd F/IAn3MTE7o/IWA6wiq7V9BJttSyBK8y =lgjh -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [OT] SecurityManager and Java Policy Files
> From: Christopher Schultz [mailto:ch...@christopherschultz.net] > Subject: Re: [OT] SecurityManager and Java Policy Files > > I was counting on you, Chuck! ;) I've kept the message, and would like to research it for my own edification. We're about done with a release cycle here, so I'm hoping time will free up Real Soon Now. (Having to replace two tires and straighten two rims due to bloody Minnesota potholes isn't helping the time situation. At least it's not flooding.) - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
RE: Tomcat 6 - slow response times outside of data center
> From: Ian Hubbard [mailto:sum.of.pri...@gmail.com] > Subject: Re: Tomcat 6 - slow response times outside of data center > > To try to cut down on the number of variables, on the client machine > I've tested both with and without hosts file entries. Have you tried a simple tracert to and from each machine to see how the network responds? > caseSensitive="false"> > > docBase="\\servername\data\iimage" > reloadable="false" caseSensitive="false"> > > docBase="\\servername\data\audio" > reloadable="false" caseSensitive="false"> > > docBase="\\servername\data\custom" > reloadable="true" caseSensitive="false"> > The above is really, really bad practice. Having elements in server.xml is strongly discouraged; they should be in either each webapp's META-INF/context.xml file, or in conf/Catalina/[host]/[appName].xml when the webapp is located outside of the 's appBase directory. Also, using a remote docBase may well be contributing to the sluggishness - best to keep a copy of the webapp on the server that's running it. Windows networking produces some really behavior on occasion. > reloadable="false" > caseSensitive="false"> > That one got you double-deployment; again, don't put elements in server.xml. > docBase="@datastore.path.root_train...@\iimage" reloadable="false" > caseSensitive="false"> > > docBase="@datastore.path.root_train...@\audio" reloadable="false" > caseSensitive="false"> > > docBase="@datastore.path.root_train...@\custom" reloadable="true" > caseSensitive="false"> > I have no idea what the above docBase references do... - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] SecurityManager and Java Policy Files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chuck, On 3/29/2010 10:08 AM, Caldarale, Charles R wrote: >> From: Christopher Schultz [mailto:ch...@christopherschultz.net] >> Subject: Re: [OT] SecurityManager and Java Policy Files >> >> Anyone? > > Sorry, no time to chase it down. I was counting on you, Chuck! ;) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuw7RUACgkQ9CaO5/Lv0PAwIACfWLvi+J42eE8cAra8dEaIoo84 vWQAnAgKCglPWmQ4SAhb5sAJbdMX4dg5 =7G3M -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6 - slow response times outside of data center
Hi Andre, Thanks for your response. My initial tests to localhost and then IP:port were in an attempt to eliminate (or at least reduce the chance) of DNS lookups being a factor -- a few years ago that beast had reared its head in relation to SSL, certificate chains, and other fun stuff. In this case SSL isn't entering into the equation, but those lookups hadn't been forgotten, which is what brought me to ask whether there's anything that could drive that sort of action in Tomcat's default config that I might be able to disable. To try to cut down on the number of variables, on the client machine I've tested both with and without hosts file entries. This morning I'm seeing slightly different behaviour, both with and without hosts file entries: - the same test previously mentioned with one of the servers typically taking 17 seconds now either takes 12+/-1 second (like another of the servers tested) or 42+/-1 second, without any middle ground...again, tomcat and the db server don't break a sweat -- they have plenty of resources free in the way of cpu/ram/throughput capacity For the parts of the equation I'm aware of, if server-side lookups were a factor wouldn't some form of significant delay be apparent when hitting tomcat from another machine within the same vlan? (Wouldn't it be normal (in a typical case) for what's happening between tomcat and the db server to remain the same, regardless of where the client tomcat's serving resides?...That being said, Tomcat itself could be doing something related to the client, or the client could be doing something in relation to the server...client-side, I'd hoped that a host file entry would cover that base...as far as Tomcat, though -- that's what I'm hoping to figure out ;) In case something jumps out at you, here's what I find in server.xml, slightly sanitized...please ask if there's anywhere else you'd like to look, and thanks again for helping: On Mon, Mar 29, 2010 at 9:54 AM, André Warnier wrote: > Hi. > > Just a very preliminary guess : could it be that different DNS lookups are > involved in the delays ? Obviously, "localhost" and IP addresses don't need > them, but maybe some of the connections between Tomcat(s) and database > server(s) are specified by name instead of IP, and/or use different DNS > servers, or in a different order ? > > > Ian Hubbard wrote: > > >> Hi all, >> >> I've got Tomcat 6 running on a few separate internal dedicated test >> machines in a data center, each with their own separate dedicated SQL >> servers. >> >> The servers themselves don't bat an eye for the tiny load i'm subjecting >> them to. For testing (using IE 6 or 7) I've been performing the same >> action, loading a simple page that uses simple queries (packet captures >> indicate that total data transferred is in the 200KB range, start to >> finish), with the following results: >> - on the webservers themselves, going to localhost:8754, pages take less >> than 1 second, all told >> - from another server in the same subnet, to tomcat via IP address to >> 8754, >> 1-2 seconds...so far, what's generally seen as normal in other >> environments >> - from a system outside the data center (but still internal, using VPN >> over >> dual T1's), again by IP, pages will load in ~17 seconds consistently using >> two of the servers in separate subnets, and 12 seconds consistently from a >> third (each server stands alone in its respective environment, hiding in >> its own little VLAN) >> >> The servers are configured similarly, as are the networks they live in. >> For >> a similar setup to other data centers more geographically distant, I can >> usually expect to see loading times of 3-5 seconds, as opposed to the >> 12/17 >> seconds being seen in these cases. If they were _all_ consistently 17 >> seconds, I'd be more inclined to point my finger firmly at the >> network...that one server that's equivalent for all intents and purposes >> completes the same task in 12, though, is a little strange. >> >> The network config side of things is beyond my direct control. There are >> likely things there that can be fine-tuned by request, if I can figure out >> what recommendation to make, and have evidence to support the >> recommendation. >> >> At this point, I'm particularly interested in whether there's anything >> within my control to improve things. The tomcat conf settings are fairly >> vanilla -- are there any common things I should look at disabling or >> changing which may improve things? (Such as settings that could result in >> lookups and
Re: Get context path in tc 5.5
On 3/29/2010 12:55 PM, Hassan Schroeder wrote: On Mon, Mar 29, 2010 at 9:22 AM, David kerber wrote: HttpServletRequest.getContextPath() - Chuck Thanks; that will work once they get into my app's functionality. Is there anything I can use to get the context path when they first connect When they "first connect" it's via a request -- so you have what you need to get that context path, by definition. Yes, I finally figured it out, though it's kind of round-about; in the SessionCreated event of my HttpSessionListener, I use: HttpSession session = event.getSession(); ServletContext context = session.getServletContext(); String contextPath = context.getResource( "/" ).toString(); As Chuck pointed out, the long-term answer is to switch to Servlet API 2.5, as implemented in TC 6, but this will do for now. D - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Get context path in tc 5.5
On 3/29/2010 12:58 PM, Caldarale, Charles R wrote: From: David kerber [mailto:dcker...@verizon.net] Subject: Re: Get context path in tc 5.5 Is there anything I can use to get the context path when they first connect Move to Tomcat 6, so you can use the 2.5 servlet APIs. I'm working toward that goal... D - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Get context path in tc 5.5
On 3/29/2010 12:22 PM, David kerber wrote: On 3/29/2010 12:05 PM, Caldarale, Charles R wrote: From: David kerber [mailto:dcker...@verizon.net] Subject: Get context path in tc 5.5 In TC 5.5.28, Java 5, how can I find the context path that was called, so I can log it? HttpServletRequest.getContextPath() - Chuck Thanks; that will work once they get into my app's functionality. Is there anything I can use to get the context path when they first connect, when I log a new session in HttpSessionListener.sessionCreated() event? I'm drawing blanks right and left in my searching for this. After some experimentation, I found that Context.getResource( "/" ) gives me what I want: I get something like "jndi:/localhost/SiteData/". All I really wanted is the "/SiteData" part, but this is close enough for my logs' purposes. D - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: using tomcat maven plugin
> From: fachhoch [mailto:fachh...@gmail.com] > Subject: using tomcat maven plugin > > I am struggling hard to setup datasource in tomact, mine is > embedded tomcat through maven plugin , please help me in > setting up dataasource for embedded tomcat You could always try answering the questions that were asked of you in the previous iteration of this thread, rather than just ignoring them: http://marc.info/?l=tomcat-user&m=126962585919427&w=2 http://marc.info/?l=tomcat-user&m=126961353929829&w=2 http://marc.info/?l=tomcat-user&m=126960904222350&w=2 - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Get context path in tc 5.5
> From: David kerber [mailto:dcker...@verizon.net] > Subject: Re: Get context path in tc 5.5 > > Is there anything I can use to get the context path when they > first connect Move to Tomcat 6, so you can use the 2.5 servlet APIs. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Get context path in tc 5.5
On Mon, Mar 29, 2010 at 9:22 AM, David kerber wrote: >> HttpServletRequest.getContextPath() >> >> - Chuck > > Thanks; that will work once they get into my app's functionality. Is there > anything I can use to get the context path when they first connect When they "first connect" it's via a request -- so you have what you need to get that context path, by definition. -- Hassan Schroeder hassan.schroe...@gmail.com twitter: @hassan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: using tomcat maven plugin
Are u trying to create data source from outside tomcat by program? -Original Message- From: fachhoch [mailto:fachh...@gmail.com] Sent: Monday, March 29, 2010 7:47 PM To: users@tomcat.apache.org Subject: using tomcat maven plugin I am struggling hard to setup datasource in tomact, mine is embedded tomcat through maven plugin , please help me in setting up dataasource for embedded tomcat -- View this message in context: http://old.nabble.com/using-tomcat-maven-plugin-tp28069941p28069941.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6 - slow response times outside of data center
Hi. Just a very preliminary guess : could it be that different DNS lookups are involved in the delays ? Obviously, "localhost" and IP addresses don't need them, but maybe some of the connections between Tomcat(s) and database server(s) are specified by name instead of IP, and/or use different DNS servers, or in a different order ? Ian Hubbard wrote: Hi all, I've got Tomcat 6 running on a few separate internal dedicated test machines in a data center, each with their own separate dedicated SQL servers. The servers themselves don't bat an eye for the tiny load i'm subjecting them to. For testing (using IE 6 or 7) I've been performing the same action, loading a simple page that uses simple queries (packet captures indicate that total data transferred is in the 200KB range, start to finish), with the following results: - on the webservers themselves, going to localhost:8754, pages take less than 1 second, all told - from another server in the same subnet, to tomcat via IP address to 8754, 1-2 seconds...so far, what's generally seen as normal in other environments - from a system outside the data center (but still internal, using VPN over dual T1's), again by IP, pages will load in ~17 seconds consistently using two of the servers in separate subnets, and 12 seconds consistently from a third (each server stands alone in its respective environment, hiding in its own little VLAN) The servers are configured similarly, as are the networks they live in. For a similar setup to other data centers more geographically distant, I can usually expect to see loading times of 3-5 seconds, as opposed to the 12/17 seconds being seen in these cases. If they were _all_ consistently 17 seconds, I'd be more inclined to point my finger firmly at the network...that one server that's equivalent for all intents and purposes completes the same task in 12, though, is a little strange. The network config side of things is beyond my direct control. There are likely things there that can be fine-tuned by request, if I can figure out what recommendation to make, and have evidence to support the recommendation. At this point, I'm particularly interested in whether there's anything within my control to improve things. The tomcat conf settings are fairly vanilla -- are there any common things I should look at disabling or changing which may improve things? (Such as settings that could result in lookups and so on, which could slow things down notably even if they aren't immediately apparent, given that the servers aren't under any notable load, and so on.) I'll happily post settings that may be of interest...I haven't done so just yet, since I don't want to inundate you with irrelevant info. Thank you for taking the time to throw any ideas you may have my way! Cheers, Ian - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat PUT not working
Michael, Many thanks for your comments, clarifications and references. I believe that these will help the Tomcat development team in their decision about implementing (or not) the getParameter family of methods on HTTP methods other than GET and POST. I did indeed leave some aspects out of my own post (such as POST "parameters" encoded as multipart/form-data, the "path-info" etc.), in order to keep the general explanation more readable. But even so, I appreciate your comments because they improve my own knowledge and will lead me to re-read these specs with hopefully a better level of understanding and precision. From the quality of your post, it sounds that you may be involved somehow in the HTTP RFC process. Is that a correct guess ? If yes, would you mind if ask you a couple of additional HTTP-related questions, off-list ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Get context path in tc 5.5
On 3/29/2010 12:05 PM, Caldarale, Charles R wrote: From: David kerber [mailto:dcker...@verizon.net] Subject: Get context path in tc 5.5 In TC 5.5.28, Java 5, how can I find the context path that was called, so I can log it? HttpServletRequest.getContextPath() - Chuck Thanks; that will work once they get into my app's functionality. Is there anything I can use to get the context path when they first connect, when I log a new session in HttpSessionListener.sessionCreated() event? I'm drawing blanks right and left in my searching for this. Dave - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Get context path in tc 5.5
> From: David kerber [mailto:dcker...@verizon.net] > Subject: Get context path in tc 5.5 > > In TC 5.5.28, Java 5, how can I find the context path that was called, > so I can log it? HttpServletRequest.getContextPath() - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Get context path in tc 5.5
In TC 5.5.28, Java 5, how can I find the context path that was called, so I can log it? I have an app that is started under two different contexts, one with the name of the .war file, and another one which is just an alias of the main one. I'm trying to log some events in a ServletContextListener, including which context was called, and can't seem to find a function to give me this. The ServletContext.getContextPath() doesn't seem to exist in the code levels I'm using??? I have found getRealPath(), but that gives the location on disk, and getServletContextName() just gives the display name as defined in web.xml. Any suggestions? Is there a function I'm missing? d - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
using tomcat maven plugin
I am struggling hard to setup datasource in tomact, mine is embedded tomcat through maven plugin , please help me in setting up dataasource for embedded tomcat -- View this message in context: http://old.nabble.com/using-tomcat-maven-plugin-tp28069941p28069941.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 6 - slow response times outside of data center
Hi all, I've got Tomcat 6 running on a few separate internal dedicated test machines in a data center, each with their own separate dedicated SQL servers. The servers themselves don't bat an eye for the tiny load i'm subjecting them to. For testing (using IE 6 or 7) I've been performing the same action, loading a simple page that uses simple queries (packet captures indicate that total data transferred is in the 200KB range, start to finish), with the following results: - on the webservers themselves, going to localhost:8754, pages take less than 1 second, all told - from another server in the same subnet, to tomcat via IP address to 8754, 1-2 seconds...so far, what's generally seen as normal in other environments - from a system outside the data center (but still internal, using VPN over dual T1's), again by IP, pages will load in ~17 seconds consistently using two of the servers in separate subnets, and 12 seconds consistently from a third (each server stands alone in its respective environment, hiding in its own little VLAN) The servers are configured similarly, as are the networks they live in. For a similar setup to other data centers more geographically distant, I can usually expect to see loading times of 3-5 seconds, as opposed to the 12/17 seconds being seen in these cases. If they were _all_ consistently 17 seconds, I'd be more inclined to point my finger firmly at the network...that one server that's equivalent for all intents and purposes completes the same task in 12, though, is a little strange. The network config side of things is beyond my direct control. There are likely things there that can be fine-tuned by request, if I can figure out what recommendation to make, and have evidence to support the recommendation. At this point, I'm particularly interested in whether there's anything within my control to improve things. The tomcat conf settings are fairly vanilla -- are there any common things I should look at disabling or changing which may improve things? (Such as settings that could result in lookups and so on, which could slow things down notably even if they aren't immediately apparent, given that the servers aren't under any notable load, and so on.) I'll happily post settings that may be of interest...I haven't done so just yet, since I don't want to inundate you with irrelevant info. Thank you for taking the time to throw any ideas you may have my way! Cheers, Ian
RE: [OT] SecurityManager and Java Policy Files
> From: Christopher Schultz [mailto:ch...@christopherschultz.net] > Subject: Re: [OT] SecurityManager and Java Policy Files > > Anyone? Sorry, no time to chase it down. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
Re: [OT] SecurityManager and Java Policy Files
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Anyone?
On 3/25/2010 4:03 PM, Christopher Schultz wrote:
> All,
>
> This is off-topic in that it doesn't really have anything to do
> specifically with Tomcat, but I would be willing to bet that readers
> would be interested in the answer. Besides, the pool of brain cells
> available to this list is rather deep and I'd love an explanation of
> policies.
>
> I recently tried to set up Tomcat 6.x running under a SecurityManager.
> As I fell down the rabbit hole, I saw that lots of things needed to be
> granted to my code, which all makes sense in general. What I don't quite
> get is the hierarchy of checks that are done.
>
> In the Tomcat SecurityManager docs
> (http://tomcat.apache.org/tomcat-6.0-doc/security-manager-howto.html),
> most of the "grants" in the policy file do not have a codeBase. Some of
> them do, such as granting AllPermission to things like bootstrap.jar,
> which presumably means that any class in bootstrap.jar can do anything
> it wants.
>
> By the way, I /have/ read
> http://java.sun.com/j2se/1.5.0/docs/guide/security/PolicyFiles.html but
> some things are still unclear.
>
> Since I didn't feel like granting permission to, say, write to my
> application log file, to the entire webapp, I chose to grant that
> privilege only to my log4j.jar file and the classes therein:
>
> grant codeBase "jar:file:@app-dir@/WEB-INF/lib/log4j-1.2.15.jar!/-" {
>permission java.io.FilePermission "@app-log-dir@/log4j.log", "write";
>permission java.util.PropertyPermission "log4j.*", "read";
> };
>
> (Don't worry about all that @app-dir@ junk: it points to the right place
> eventually, and I didn't feel like replacing it with something plausible
> for publication).
>
> Anyhow, this would seem to work great, except that I also configure
> commons-logging to use the log4j logger, and the commons-logging library
> tries to initialize the log4j logger at some point, which throws
> permission errors. Hmm. So, I tried adding this, too:
>
> grant codeBase
> "jar:file:@app-dir@/WEB-INF/lib/commons-logging-1.1.1.jar!/-" {
>permission java.io.FilePermission "@app-log-dir@/log4j.log", "write";
>permission java.util.PropertyPermission
> "org.apache.commons.logging.*", "read";
>permission java.util.PropertyPermission "log4j.*", "read";
> };
>
> That seemed to get me further through the process but then my own
> application code was failing because... guess what? My code wasn't
> allowed to call code that /was/ allowed to write to log4j.log. :(
>
> Okay, fine:
>
> grant codeBase "file:@app-dir@/WEB-INF/classes/-" {
>permission java.io.FilePermission "@app-log-dir@/log4j.log", "write";
>permission java.util.PropertyPermission
> "org.apache.commons.logging.*", "read";
>permission java.util.PropertyPermission "log4j.*", "read";
> };
>
> This seemed to make things happy again, as far as the log file was
> concerned. There are other issues for me to deal with, but this example
> is illustrative: it appears that the SecurityManager is enforcing
> permissions along with the call chain, not just with the finest-grained
> code being checked for its permissions.
>
> First: do I have this right? The JVM makes sure that permissions are in
> place for every class on the call stack when such permissions are
> checked? I suppose that would make sense, because then you could say
> "well, my JDBC driver does the actual connecting to the database, but I
> certainly don't want some rogue code in my webapp to create such a
> connection... only allow Tomcat to create connections on my behalf".
>
> Second - as a corollary to the first - is this why most examples of
> policy grants simply say "grant { whatever }" to allow all code running
> in the JVM to have that permission? Because the alternative is so
> onerous that nobody wants to do it? Well, I kinda want to do it, so I
> just want to know what the rules are.
>
> Third: doesn't this make performance really suck?
>
> Anyone who could shed some light on my understanding would certainly be
> appreciated. I'm happy to read any references posted as well.
>
> Thanks,
> -chris
- -
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkuws9AACgkQ9CaO5/Lv0PAOwQCgj7lfQLwbrtTjWZtnDi3wlgDD
BHgAn27/t9LOKS3e/2oHRXYHOv3NcTvH
=vE96
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat PUT not working
André Warnier wrote: > > The area of contention here is whether a HTTP PUT request can or not > have "parameters", and whether such parameters can or not be encoded as > part of the HTTP body of a PUT request (or as part of the URL query > string of the request). As far as I can tell, this is a Tomcat issue, not an HTTP one. Technically, HTTP requests do not have "parameters", regardless of the HTTP method (GET, POST, etc). HTTP requests have a Request-URI, which can have a query-string part; headers; and in some cases a content-body (aka "entity"). The server and anything it delegates the request to can make use of any of those in determining how to handle the request. But RFC 2616 does not define request "parameters". That is an informal concept, as far as HTTP is concerned. Since the HTTP/1.1 specification (RFC 2616) lets a PUT request include a query-string as part of its Request-URI (see below), if a query-string can be treated as "parameters", then a PUT request can have parameters. The same argument applies to the request headers and content-body of a PUT request. (Note that request headers are commonly used to convey metadata about the content-body to server-side application code; but they're not restricted to that purpose.) > Basically (and roughly), > - for a GET (which does not have a body), such request parameters are > encoded as part of the request URL "query string" part True, though it would be more accurate to say that since a GET request cannot include a content-body, its only channels for notional "parameters" are the query-string and the request headers. > - for a POST request (which has a body), the parameters are encoded the > same way, but are contained in the HTTP body of the request. Any HTTP request method other than CONNECT, including a POST request, can include a query-string in its Request-URI. See 2616 3.2, 5.1.2, and 9. Also, the other parts of the Request-URI can be treated as application parameters. See for example the definition of "path-info" in the CGI/1.1 specification: the CGI program is identified by the part of the abs_path that includes the actual name of an executable (as defined by the server), but the abs_path can contain additional components after that which are made available to the program (possibly after transformation by the server) via the environment. And the "parameters" in the content-body of a POST request do not need to be URL-encoded. Some HTTP applications, such as HTML, do define POST entities that are URL-encoded - notably HTML's use of URL-encoding for form name/value pairs. But the POST request content-body can be any stream of octets, and its interpretation is left to whatever processes the request. > For PUT requests however, there is no mention anywhere (in the > applicable specs) of parameters. 2616 9.6 says that a PUT request includes a Request-URI. 5.1.2 says that will be an absoluteURI or an abs_path. (A PUT request must refer to a resource, so "*" is not allowed; and the fourth option, an authority, is only allowed for the CONNECT request method.) And 3.2.2 includes the query string as part of an http_URL. (RFC 2616 *is* somewhat sloppy in this regard, because 3.2.2 incorrectly separates abs_path and query, which suggests that eg a GET request cannot be made using an abs_path with a query string - ie, that it would have to be made using an absoluteURI in order to a query string. There are various proposed fixes for this; see eg i58 in the HTTP rfc2616bis issues list at [1].) > In fact, the HTTP RFC definition of a PUT request seems to indicate that > the body contains the "resource" that the client wants the server to > store at the location corresponding to the indicated request URL. Correct. The intention of the PUT request is to ask the origin server to store an entity; the content-body contains the entity, and the Request-URI names it. > For all these reasons, currently Tomcat does not support the > getParameters() family of methods, when the request method is PUT. This is a Tomcat limitation, not an HTTP one. It's not a conformance issue, because RFC 2616 doesn't require the server do anything in particular with the query-string. But it does permit a query-string in a PUT Request-URI. > It is possible that other servlet engines support this, but in that case > it has to be considered as an optional add-on, not as something that is > required by the HTTP RFC nor the Servlet Spec. Agreed. > But the crux of the matter is, that if a (REST) web application would > depend on that feature to be available in an HTTP server or a Servlet > Engine, then that application is not portable, because the applicable > specifications do not mention this as a mandatory feature of either of > them. Agreed. Of course, even if you limit yourself to conforming HTTP servers, it can be difficult to be completely portable; HTTP/1.1 doesn't have all that many requirements. A conforming HTTP/1.1 server only has to support GET and HEAD, for
Re: Upgrade tomcat 6 to a new point release on windows
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dale, On 3/28/2010 11:53 PM, dale77 wrote: > what is the procedure for upgrading to the latest point release of tomcat 6 > on windows? > > We are on 6.0.18 running tomcat as a windows service. What is the > recommended procedure for upgrade? > > Does the current windows installer do the right thing to in-place upgrade > 6.0.18 to 6.0.26? Or is this an uninstall, reinstall thing? I don't believe Tomcat's Microsoft Windows installer does "upgrades". I don't run on Microsoft Windows, but this procedure should generally get you going: 0. Shut-down your old Tomcat instance. 1. Install the new version of Tomcat into a separate directory from the old one, and have the installer install the service for you. 2. Copy your webapps from old_tomcat\webapps\* to new_tomcat\webapps. Copy any old_tomcat\conf\[service]\[host]\*.xml files to new_tomcat\conf\[service]\[host]. 3. If this really is a point-release change, you can probably get away with copying conf/server.xml, conf/catalina.policy, conf/logging.properties, and anything else you need from the conf directory into new_tomcat\conf. You may consider starting over with a new server.xml and merging-in any changes from the old one ... typically you should only be configuring s and any clustering you need in server.xml: all webapps should have been taken care of in step #2. 4. Copy any custom libraries that you put into old_tomcat\lib to new_tomcat\lib. This would be where your JDBC driver usually lives and maybe other shared libraries. 5. Start the newly-installed service and check everything out. Hope that helps, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuwsucACgkQ9CaO5/Lv0PAusACfaY1oL5d8KJgYxPPSITrdIYkx yREAn32JGxwiYjFTt7ltgnXs41eGFFeR =M+yb -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Win7 calling native code via JNI
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Patrick,
On 3/27/2010 9:07 PM, Patrick Flaherty wrote:
> There is only a 32 bit JVM on the machine. The bridge dll has not been
> recompiled since
> mid '08. If it was an incompatibility with the Microsoft Runtime
> Library wouldn't you expect
> the Service Version to do the same ?
It's possible that different libraries are being picked-up in the two
different environments (system service vs. your own account). Is this
the file you expected to get?
C:\Windows\syswow64\msvcrt.dll
If you look at the code you will see I try to create a file on the
root of the C drive (remotedebug.txt) and
>
> The file does get created via the Service but not standalone, weird.
> If it was crashing as a result of the file creation, would you expect
> to see the CPPinit at the top of the stack trace ?
I see your Java method cppInit at the top of the stack trace, but I
can't tell what is happening once your library is running. RRBridge.dll
appears twice on the stack in the backtrace with no debugging
information, but you can at least tell that your DDL is calling itself
at some point.
Your file won't get created at all given this line:
//FILE *fp = fopen("C:\\remotedebug.txt", "at");
...but your cppInit method does make these calls (presumably to other
functions in your library):
RSWP_DBL (looks like a macro)
RSWP_Volumes
RSWP_CheckHasp
RSWP_SetDataBase
What debugging information gets emitted before the crash? Is your debug
logger set to auto-flush? If not, you could be missing crucial logging
information that occurred just before the crash.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkuwsZwACgkQ9CaO5/Lv0PDFPQCdHTkZpKCO8YDfDq6HuEtDWEKG
ARwAn07wq6r0Ici/BBbh3krgv6MeTdat
=U/UC
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat PUT not working
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 André, On 3/28/2010 10:23 AM, André Warnier wrote: > For GET and POST requests, both the HTTP RFC and the Servlet Spec > provide some answers and describe how it is done. > Basically (and roughly), > - for a GET (which does not have a body), such request parameters are > encoded as part of the request URL "query string" part > - for a POST request (which has a body), the parameters are encoded the > same way, but are contained in the HTTP body of the request. ... and, for completeness, POST requests may also have GET-style URL parameters which are merged-together with those gathered from the POST body so the servlet doesn't have to consult two different "places" for parameter values. > In fact, the HTTP RFC definition of a PUT request seems to indicate that > the body contains the "resource" that the client wants the server to > store at the location corresponding to the indicated request URL. +1 > Reading the PUT request body yourself, and parsing it into parameters > yourself, is on the other hand perfectly supported and should work > anywhere. Yup: also, you might be able to write a filter that changes the request method from PUT to POST in order to trick Tomcat into parsing the request body for you. That's an ugly hack, but at least you don't have to go parsing your own request bodies to do that. On the other hand, using PUT to pass parameters in the body doesn't sound like it matches any well-known specification, recommendation, or proposal. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuwrxYACgkQ9CaO5/Lv0PA3ywCeMqOtAF0tQKqJTDYUhaspz+iJ gToAnROaNvDj1NFDRCoBby0VqP52gPqd =GB6v -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Proposal : port mod_expires in java as ExpiresFilter Servlet Filter
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Cyrille,
On 3/26/2010 12:43 PM, Cyrille Le Clerc wrote:
> I have proposed with bugzilla 48998 a port of Apache mod_expires in
> Java as ExpiresFilter Servlet Filter.
Cool.
> I detailed a standalone version of this filter on
> http://code.google.com/p/xebia-france/wiki/ExpiresFilter . Moreover, I
> tried my best to provide very detailed javadocs and docs (in filter.html).
>
> The proposed contribution is slightly different than the standalone
> one because it uses Tomcat logging, few Servlet 3 enhancements and
> Tomcat engine in the test cases.
I read-through your code on code.google.com and I can see a couple areas
where I think improvements might be made:
- - In getExpirationDate, you check for the local 'configuration' being
null several times in a row. In each case, the configuration may be set
given a different 'level' of configuration. If the configuration gets
set, several checks must still be made to see if it is null. You could
mail out early and avoid some of these checks like this:
if(configuration == null) {
configuration = ...;
if(configuration == null) {
// try another strategy
configuration = ...;
if(configuration == null) {
...
}
}
}
I think can save a bit of CPU time without much in the way of code
complexity.
- - You might be able to wrap the Response class and check for the setting
of the Content-Type header, instead of wrapping the response in order to
intercept the first buffer flush to the client. Do you think that would
work? It certainly would remove a lot of complexity from your code.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkuwqQwACgkQ9CaO5/Lv0PDdwgCgrSHwmgUTDWybmk6/G1+AqNzY
kCQAn0zVrQBARihaoQkfBJRtKYkjvsjs
=kBWG
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: AW: Shutdown hook for correctly unloading drivers
On 29/03/2010 10:19, Steffen Heil wrote: > Hi > >>> I am thinking about a strategy to iterate over all running threads and >>> interrupt (and if absolutely necessary stop) all threads started by a >>> certain classloader (not sure if it is possible, but I suspect so - > might >>> require instrumention though.) >> Tomcat can already do this. > > Great. Where can I find the code for this and how is it enabled? > Is there any documentation of that feature? http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/loader/WebappClassLoader.java?view=annotate Look for clearReferencesXXX() methods http://wiki.apache.org/tomcat/MemoryLeakProtection http://tomcat.apache.org/tomcat-6.0-doc/config/context.html clearReferencesStopThreads >> You don't want to use it though. In my testing the JVM crashed about 50% > of the time. > > I don't understand this. It should definitely not crash. (It might (but > should not) leak resources however...) There is no safe way to terminate an arbitary Thread. >> Tomcat will also tell you which threads weren't stopped along with a bunch > of other memory leak checks. > > Where can I find this? I would be very much interested. Never seen that. See above. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AW: AW: Shutdown hook for correctly unloading drivers
Hi > > I am thinking about a strategy to iterate over all running threads and > > interrupt (and if absolutely necessary stop) all threads started by a > > certain classloader (not sure if it is possible, but I suspect so - might > > require instrumention though.) > Tomcat can already do this. Great. Where can I find the code for this and how is it enabled? Is there any documentation of that feature? > You don't want to use it though. In my testing the JVM crashed about 50% of the time. I don't understand this. It should definitely not crash. (It might (but should not) leak resources however...) > Better to fix the thread leak. For sure. > Tomcat will also tell you which threads weren't stopped along with a bunch of other memory leak checks. Where can I find this? I would be very much interested. Never seen that. Beside my interest for all the above, my webapp has a plugin mechanism that also has to be able unload plugins, so I am working on code to make that really happen. Relying on these plugins developers is not that good idea. BTW: I am also planning on deadlock detection and on restarting blocking modules. Regards, Steffen smime.p7s Description: S/MIME cryptographic signature
Re: Tomcat app. can no longer connect to MySQL
Konstantin Kolinko wrote: 2010/3/28 fred basset : Caused by: org.hibernate.HibernateException: Hibernate Dialect must be explicitly set at org.hibernate.dialect.DialectFactory.determineDialect(DialectFactory.java:57) at org.hibernate.dialect.DialectFactory.buildDialect(DialectFactory.java:39) at org.hibernate.cfg.SettingsFactory.determineDialect(SettingsFactory.java:426) at org.hibernate.cfg.SettingsFactory.buildSettings(SettingsFactory.java:128) at org.hibernate.cfg.Configuration.buildSettings(Configuration.java:2009) at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1292) Looks like your Hibernate configuration is incomplete. Either that, or you don't have access from Tomcat server to MySQL server. Notice other exception: Caused by: java.net.ConnectException: Connection refused Make sure that it is possible to open MySQL port, e.g: tomcat-server> telnet mysql-server.company.com 3306 Regards, Ognjen - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
