A typo error in WebRuleSet
Hi, It seems that there is one typo error on the line 523 of WebRuleSet file, it should be configureInjectionRules(digester, web-app/ejb-local-ref/); --- configureInjectionRules(digester, web-app/resource-env-ref/); -- Ivan
Re: FileDirContext returns the path directly without checking whether the target file really exists
On 29/07/2010 01:45, Ivan wrote:
Thanks, Mark, if you mean the method getRealPath in BaseDirContext, I have
checked it.
---
public String getRealPath(String name) {
if (!aliases.isEmpty()) {
AliasResult result = findAlias(name);
if (result.dirContext != null) {
return result.dirContext.doGetRealPath(result.aliasName);
}
}
// Next do a standard getRealPath()
String path = doGetRealPath(name); -- I think this invocation
will never return null in the FileDirContext implementation, right ? So does
it mean that if FileDirContext is used, no need to consider the resources in
the META-INF/resources embed in the jar files.
Correct. I think the check of META-INF/resourcs below could be removed.
Mark
if (path != null)
return path;
// Check the alternate locations
for (DirContext altDirContext : altDirContexts) {
if (altDirContext instanceof BaseDirContext){
path = ((BaseDirContext) altDirContext).getRealPath(
META-INF/resources/ + name);
if (path != null)
return path;
}
}
// Really not found
return null;
}
---
2010/7/29 Mark Thomas ma...@apache.org
On 28/07/2010 14:11, Ivan wrote:
Thanks, if possible, could you please show me where it is ? I am really
interested in those details :-)
BaseDirContext
Mark
-
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: A typo error in WebRuleSet
On 29/07/2010 08:10, Ivan wrote: Hi, It seems that there is one typo error on the line 523 of WebRuleSet file, it should be configureInjectionRules(digester, web-app/ejb-local-ref/); --- configureInjectionRules(digester, web-app/resource-env-ref/); Fixed: http://svn.apache.org/viewvc?rev=980347view=rev Thanks. Mark Note: This sort of thing technically belongs on the dev list but I wouldn't worry too much for simple one liners like this. The community is generally far more tolerant of the occasional dev issue on the users list than it is of a users issue on the dev list. However, any long discussion would probably get moved to the dev list. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: FileDirContext returns the path directly without checking whether the target file really exists
Thanks, Mark.
So in other words, those descriptions in the spec for META-INF/resources
make no sense. right ?
2010/7/29 Mark Thomas ma...@apache.org
On 29/07/2010 01:45, Ivan wrote:
Thanks, Mark, if you mean the method getRealPath in BaseDirContext, I
have
checked it.
---
public String getRealPath(String name) {
if (!aliases.isEmpty()) {
AliasResult result = findAlias(name);
if (result.dirContext != null) {
return result.dirContext.doGetRealPath(result.aliasName);
}
}
// Next do a standard getRealPath()
String path = doGetRealPath(name); -- I think this
invocation
will never return null in the FileDirContext implementation, right ? So
does
it mean that if FileDirContext is used, no need to consider the resources
in
the META-INF/resources embed in the jar files.
Correct. I think the check of META-INF/resourcs below could be removed.
Mark
if (path != null)
return path;
// Check the alternate locations
for (DirContext altDirContext : altDirContexts) {
if (altDirContext instanceof BaseDirContext){
path = ((BaseDirContext) altDirContext).getRealPath(
META-INF/resources/ + name);
if (path != null)
return path;
}
}
// Really not found
return null;
}
---
2010/7/29 Mark Thomas ma...@apache.org
On 28/07/2010 14:11, Ivan wrote:
Thanks, if possible, could you please show me where it is ? I am really
interested in those details :-)
BaseDirContext
Mark
-
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
--
Ivan
Re: FileDirContext returns the path directly without checking whether the target file really exists
On 29/07/2010 09:08, Ivan wrote:
Thanks, Mark.
So in other words, those descriptions in the spec for META-INF/resources
make no sense. right ?
Not sure what you mean. I don't see any issues with the spec. I do think
the implementation does something that is guaranteed to never succeed.
The resource JARs never get expanded so getRealPath() will always return
null - there is no point checking.
Mark
2010/7/29 Mark Thomas ma...@apache.org
On 29/07/2010 01:45, Ivan wrote:
Thanks, Mark, if you mean the method getRealPath in BaseDirContext, I
have
checked it.
---
public String getRealPath(String name) {
if (!aliases.isEmpty()) {
AliasResult result = findAlias(name);
if (result.dirContext != null) {
return result.dirContext.doGetRealPath(result.aliasName);
}
}
// Next do a standard getRealPath()
String path = doGetRealPath(name); -- I think this
invocation
will never return null in the FileDirContext implementation, right ? So
does
it mean that if FileDirContext is used, no need to consider the resources
in
the META-INF/resources embed in the jar files.
Correct. I think the check of META-INF/resourcs below could be removed.
Mark
if (path != null)
return path;
// Check the alternate locations
for (DirContext altDirContext : altDirContexts) {
if (altDirContext instanceof BaseDirContext){
path = ((BaseDirContext) altDirContext).getRealPath(
META-INF/resources/ + name);
if (path != null)
return path;
}
}
// Really not found
return null;
}
---
2010/7/29 Mark Thomas ma...@apache.org
On 28/07/2010 14:11, Ivan wrote:
Thanks, if possible, could you please show me where it is ? I am really
interested in those details :-)
BaseDirContext
Mark
-
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: FileDirContext returns the path directly without checking whether the target file really exists
The below description from the spec says that resources inside the
META-INF/resources directory of JAR files might be consider only if the
container has unpacked them.
Since the getRealPath is used to return a virtual path, when will the
unpackaged location of resources directory be considered ? Only when the war
package is not unpacked, but the META-INF/resources directory are extracted
?
Thanks !
---
Resources inside the META-INF/resources directory of JAR file must be
considered only if the container has unpacked them from their containing JAR
file
when a call to getRealPath() is made, and in this case MUST return the
unpacked
location.
---
2010/7/29 Mark Thomas ma...@apache.org
On 29/07/2010 09:08, Ivan wrote:
Thanks, Mark.
So in other words, those descriptions in the spec for META-INF/resources
make no sense. right ?
Not sure what you mean. I don't see any issues with the spec. I do think
the implementation does something that is guaranteed to never succeed.
The resource JARs never get expanded so getRealPath() will always return
null - there is no point checking.
Mark
2010/7/29 Mark Thomas ma...@apache.org
On 29/07/2010 01:45, Ivan wrote:
Thanks, Mark, if you mean the method getRealPath in BaseDirContext, I
have
checked it.
---
public String getRealPath(String name) {
if (!aliases.isEmpty()) {
AliasResult result = findAlias(name);
if (result.dirContext != null) {
return
result.dirContext.doGetRealPath(result.aliasName);
}
}
// Next do a standard getRealPath()
String path = doGetRealPath(name); -- I think this
invocation
will never return null in the FileDirContext implementation, right ? So
does
it mean that if FileDirContext is used, no need to consider the
resources
in
the META-INF/resources embed in the jar files.
Correct. I think the check of META-INF/resourcs below could be removed.
Mark
if (path != null)
return path;
// Check the alternate locations
for (DirContext altDirContext : altDirContexts) {
if (altDirContext instanceof BaseDirContext){
path = ((BaseDirContext) altDirContext).getRealPath(
META-INF/resources/ + name);
if (path != null)
return path;
}
}
// Really not found
return null;
}
---
2010/7/29 Mark Thomas ma...@apache.org
On 28/07/2010 14:11, Ivan wrote:
Thanks, if possible, could you please show me where it is ? I am
really
interested in those details :-)
BaseDirContext
Mark
-
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
--
Ivan
Instance management
Hi, I have apache-tomcat-6.0.20 and jdk1.6.0_18 installed in one centos 5.5 with three instances running using the CATALINA_BASE variable resource. The developments can shutdown and run own applications with a PROBE application. I would like to management(shutdown e run) all the instances with an web application, someone knows a application java that does this? Thanks, Alex Carvalho
Re: Fire off asynch task in Tomcat.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 André, On 7/23/2010 2:22 PM, André Warnier wrote: You can of course imagine which language I was thinking of. #!/usr/bin/perl use Perl::MailSendFromDbQueue; go(mydb, user, pass); #end -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxRnfEACgkQ9CaO5/Lv0PBEygCeOq8mr991YWfBmcSIvhL+U7I7 /yUAnRCCf/oNX8vP1hc67sNiX0ICHiyk =Ai6J -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat stops loading page half way through on runtime exception
I'm getting a runtime NullPointerException (just code in dev I'm working on). But I notice that Tomcat only loads half the page and stops roughly around the exception point (+/- some buffer amount it looks like). I'd much prefer a more consistent response (at this time, just the standard exception page). Is there a way to ensure the exception page is displayed on exceptions (or in the future to ensure that the defined pretty error page is displayed)? I really just want to avoid the potential of half-loaded pages, they look horrid. Thanks, David - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat stops loading page half way through on runtime exception
From: David Parks [mailto:davidpark...@yahoo.com] Subject: Tomcat stops loading page half way through on runtime exception But I notice that Tomcat only loads half the page and stops roughly around the exception point Tomcat doesn't load pages, it sends them; the browser loads pages. I'd much prefer a more consistent response (at this time, just the standard exception page). What is the standard exception page? If you're referring to the standard error page Tomcat generates, it can't send it if your webapp has already committed all or a portion of the response (via flush(), for example). You shouldn't be doing that until you know you're going to be able to complete the processing of the request. Is there a way to ensure the exception page is displayed on exceptions (or in the future to ensure that the defined pretty error page is displayed)? Fix your webapp to not send partial responses. Nothing Tomcat can do if you've already committed the response; there's no way to recall what you've already sent. - 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
JNDI not available from ServletContextListener
Can anybody reproduce the bug I'm getting in Tomcat 6.0.29, or is it just me? I'm trying to access a DataSource via JNDI from a ServletContextListener. I find that my InitialContext has no bindings at all in the ServletContextListener.contextInitialized() method. It makes no difference whether I declare the DataSource in META-INF/context.xml or in conf/server.xml (with a ResourceLink in META-INF/context.xml). A Bugzilla bug was filed for this behavior under Tomcat 7, and the bug was patched. https://issues.apache.org/bugzilla/show_bug.cgi?id=49132 That bug report includes a bare-bones Eclipse project that exhibited the error under Tomcat 7. When I deploy that project on Tomcat 6.0.29, I get the same behavior that was reported under Tomcat 7, consistent with my original DataSource problem. I reported my experience in Bugzilla but it was rejected. https://issues.apache.org/bugzilla/show_bug.cgi?id=49673 Perhaps I've configured something wrong - does anybody else get the same behavior with the Eclipse project tomcat7-web-test under Tomcat 6.0.29? Or is there something wrong with the posted project? --Steve
RE: JNDI not available from ServletContextListener
I guess the maintainers know what they're doing, because my original DataSource problem turns out to be a configuration problem. I still don't know why the Eclipse project fails for me, but I'm assuming it's some kind of deployment problem. Thanks, case closed, --Steve From: Steve Mitchell Sent: Thursday, July 29, 2010 5:49 PM To: 'users@tomcat.apache.org' Subject: JNDI not available from ServletContextListener Can anybody reproduce the bug I'm getting in Tomcat 6.0.29, or is it just me? I'm trying to access a DataSource via JNDI from a ServletContextListener. I find that my InitialContext has no bindings at all in the ServletContextListener.contextInitialized() method. It makes no difference whether I declare the DataSource in META-INF/context.xml or in conf/server.xml (with a ResourceLink in META-INF/context.xml). A Bugzilla bug was filed for this behavior under Tomcat 7, and the bug was patched. https://issues.apache.org/bugzilla/show_bug.cgi?id=49132 That bug report includes a bare-bones Eclipse project that exhibited the error under Tomcat 7. When I deploy that project on Tomcat 6.0.29, I get the same behavior that was reported under Tomcat 7, consistent with my original DataSource problem. I reported my experience in Bugzilla but it was rejected. https://issues.apache.org/bugzilla/show_bug.cgi?id=49673 Perhaps I've configured something wrong - does anybody else get the same behavior with the Eclipse project tomcat7-web-test under Tomcat 6.0.29? Or is there something wrong with the posted project? --Steve
