On 6/19/2012 11:22 AM, Mark Thomas wrote:
Compare the definition of the ResultSet interface in the version of the
JDK the class was compiled with with the definition in the version of
the JDK you are running with.
Thanks, that explains it: as I wrote before, the abstract DelegatingResultSet
met
I just noticed that the DelegatingResultSet object handed by Tomcat
sports a slew of abstract methods even though the class itself is
not declared abstract. In Tomcat 7.0.x there are only 2 such methods:
the two getObject methods taking a Class as second argument, which are
also the only two metho
You guys have a chip on your shoulder. This is Java.
"M", "m", "G" and "g" are accepted as
sizes by all the -Xm? options, so why not by Tomcat.
M and G are size units, too.
Other than dudes with an attitude like you, nobody
refers to 64M as 67108864.
-- O.L.
---
What is the syntax for the maxPostSize Connector parameter:
are notations like 1M or 1G recognized? That would be expected,
even thought the docs: http://tomcat.apache.org/tomcat-7.0-doc/config/http.html
are mum about it.
Thanks,
-- O.L.
ServerFactory is gone from Tomcat 7. What is now the preferred
way of getting hold of the server and, later down the road, of
running services?
You should really expand the migration document. To say that
"there have been many changes" and we "should review the JavaDoc
for the relevant API" is ra
On 3/16/2011 2:07 PM, Caldarale, Charles R wrote:
The above would indicate something's seriously wrong with the installed JDK.
That can't be: it's a recent download of jdk-6u24-windows-i586.exe and I just
performed a clean reinstall. I made sure the c:\Java\j2sdk1.6.0 was empty
first.
What ha
On 3/16/2011 2:33 PM, Mladen Turk wrote:
OK, that seems fine. However I wonder from where the first one comes?
[2011-03-16 06:12:39] [info] ( :0 ) Starting service...
[2011-03-16 06:12:39] [debug] ( javajni.c:195 ) Invalid RuntimeLib
'C:\Java\j2sdk1.6.0\bin\server\jvm.dll'
It seems that you hav
On 3/16/2011 7:14 AM, Mladen Turk wrote:
What's the debug output with client VM?
[2011-03-16 11:21:52] [debug] ( prunsrv.c:1494) Commons Daemon procrun log
initialized
[2011-03-16 11:21:52] [info] ( :0 ) Commons Daemon procrun (1.0.5.0
32-bit) started
[2011-03-16 11:21:52] [info]
To be absolutely sure I uninstalled both JRE and JDK, manually
removing anything left behind, and reinstalled. This time the
JRE did not have a server JVM indeed, so maybe another program
had copied it. However the JDK has one and if I use it for the
Tomcat server and later try to start it (with d
On 3/16/2011 2:50 AM, Konstantin Kolinko wrote:
What version of JRE are you using? The latest 6u24 one does not have the file.
It is 6u24. I did not copy anything.
In addition, I already told you that I get the same error if I use the server
JVM from the JDK.
-- O.L.
--
On 3/15/2011 8:34 PM, Konstantin Kolinko wrote:
"/tomcat.jks" is a relative path on Windows, but absolute one on Linux.
OK. I thought Tomcat would always interpret it as a relative path.
Try with "${catalina.home}/tomcat.jks"
Yes, that works on both systems, so it is the safe option.
Thank
On 3/15/2011 8:28 PM, Konstantin Kolinko wrote:
Saying it does not make so. I assure you that both the JRE and the
JDK include the bin/server/jvm.dll.
On Linux yes. On Windows no. Have you looked there? Or you have a 64-bit JRE?
Of course I have looked there! And no I don't have a 64bit JRE.
In the HTTPS Connector element of my server.xml I have
keystoreFile="/tomcat.jks". This works fine on Windows
but fails on Linux with "java.io.FileNotFoundException:
/tomcat.jks (No such file or directory)". Of course
$CATALINA_HOME/tomcat.jks exists and is readable. Any
idea? Tomcat was started a
On 3/15/2011 7:44 PM, Konstantin Kolinko wrote:
Windows versions of JDK do have server JVM, while JREs do not.
Saying it does not make so. I assure you that both the JRE and the
JDK include the bin/server/jvm.dll.
In any case this is a red herring because repointing --Jvm to the
JDK sever jvm.
On 3/15/2011 4:56 PM, Caldarale, Charles R wrote:
You have a *server* JVM installed on Windows XP? Want to verify that?
Like I said, $JAVA_HOME/bin/server/jvm.dll is there. I did nothing
special: I just ran the installer.
If --StartPath is omitted Tomcat attempts to start in the
local direct
My Tomcat service (since 7.0.8) would die with "Commons Daemon
procrun stdout initializedError occurred during initialization
of VM Unable to load native library" when I tried to start it.
I finally traced got fed up with starting it from the command
line and traced it down to this option that is
On 3/7/2011 1:27 PM, Konstantin Kolinko wrote:
Why do you forbid HEAD? IMHO it should have the same constraints as
GET, because browsers use them together.
OK. That doesn't answer my question, though.
But in the meantime I realized that in the access log there are pairs
of entries with status
On 3/7/2011 8:00 AM, הילה wrote:
How do I know if I use the new pool?
just by specifying the
org.apache.tomcat.jdbc.pool.DataSourceFactory
AFAICT yes.
what is the advantages of using the new pool?
in which cases should I use it?
See http://people.apache.org/~fhanik/jdbc-pool/jdbc-pool.html
I put this in my webapp's web.xml, then intent being to
allow GET and POST over https and nothing else:
forbidden
/*
HEAD
PUT
DELETE
OPTIONS
TRACE
secure
/*
GET
POST
It's quite unclear, when using ServletContext.log(...), how one can
specify the logging level. Maybe it's impossible?
-- O.L.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-
Thanks! But this:
factory="org.apache.tomcat.jdbc.pool.DataSourceFactory"
is the default, I believe. Didn't you say you were using something else?
-- O.L.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For addi
Can we see the relevant part of your context.xml, too?
Thanks,
-- O.L.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
NB: Sorry if this a double posting but for some reason it didn't get through
the first time.
On 3/1/2011 7:52 PM, Caldarale, Charles R wrote:
> In the 3.0 spec, it's in section 11.6 (was 10.6 in the 2.5 version). The key
statements are:
Yes, that's what I was referring to.
> Because of the s
It's in the servlet spec.
Sorry, can you give me the actual section: are you
referring to §11.6?
-- O.L.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.
On 3/1/2011 3:54 PM, Caldarale, Charles R wrote:
Anything using an org.apache class is Tomcat-specific, and
> therefore not portable.
Oh, right. I had not picked up that LifecycleListener itself is
a Catalina class.
Still, the basic issue is not about the listener per se but how
the app server
On 3/1/2011 3:14 PM, Caldarale, Charles R wrote:
Normally, you would put such conditional activation code in a
ServletContextListener, and have it throw an exception if things
> are not to your liking. Doing so would prevent any further use
> of the webapp.
OK but I have the same question as to
On 3/1/2011 2:57 PM, Mark Thomas wrote:
Providing you throw an Error, Tomcat is guaranteed not to start.
OK! Just to be 100% clear, this is a Tomcat thing, not a servlet
spec thing, right? Just wondering whether it's portable.
-- O.L.
This is a follow-up on an earlier thread on killing
a servlet at startup. To recap., this is best done
by throwing a suitable exception in its init method,
as per §2.3.2.1 of the servlet spec.
But what if the webapp has several servlets and you
want to abort (or undo) the loading of the whole
col
On 2/28/2011 8:18 PM, Mark Thomas wrote:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/security/SecurityListener.java?view=annotate
This is brand new, isn't it? I can't find it in the 7.0.8 sources.
So it may throw a java.lang.Error at Lifecycle.BEFORE_INIT_EVENT
time but
On 2/28/2011 6:09 PM, Caldarale, Charles R wrote:
The servlet, or the webapp?
The webapp in this case: the servlet that might fail is the
"worker" servlet, the others more in a supporting role (e.g.,
UI). So if it fails the whole webapp should shut down.
Why don't you simply throw a ServletEx
On 2/28/2011 6:06 PM, Mark Thomas wrote:
If you want to stop a single Servlet then Servlet.init() is the
place to it. See section 2.3.2 of the Servlet 3.0 spec.
I.e., the exception throwing approach suggested by C. Caldarale in
the next answer. Yes, it's neat. So I was overcomplicating it.
or
Your application may be on a shared Tomcat instance someday
and System.exit is really bad in that case.
True. So let's kill the servlet instead. But it's still unclear
how you'd do that because from the ServletConfig you can get the
ServletContext but from the ServletContext you can no longer ge
Doing this from a servlet begs the question how you are going
to restart it.
Not an issue: I want to shut it down at startup if some needed
resources cannot be found. No pint restarting it then.
I'm also curious why you want tot do this but System.exit() will
have exactly the same result as us
Is there a programmatic way to retrieve it from within
a webapp, more exactly from within Servlet.init()? I
can't find one. Same question for the actual command.
As you may have guessed, I want to shut down Tomcat by
opening a socket and sending it a SHUTDOWN or whatever.
Maybe there is a less lo
34 matches
Mail list logo
