Re: Tomcat 8.0.0-RC5: asynchron IO and back pressure with ReadListener
Thanks Rémy and Mark for the quick feedback and explanations! On Mar 19, 2014 6:40 PM, Mark Thomas ma...@apache.org wrote: On 19/03/2014 17:04, Rémy Maucherat wrote: 2014-03-19 17:47 GMT+01:00 Yann Simon yann.simon...@gmail.com: This is because you're forking a thread, it won't concurrently invoke the two events (which would be invalid). Can you explain more please? I have difficulties to understand your sentence. It means the container has to wait until onReadPossible completes to call onDataAvailable. I think Rémy meant Tomcat waits for onReadPossible() to complete before calling onAllDataRead() If you look at the traces from the sample code, you'll see that the onDataAvailable end message always appears before onAllDataRead which is all you can rely on. You are seeing slightly odd behaviour because you are spawning a new thread to do the read. If you do that you have to handle the case that your new thread may trigger the onAllDataRead event and handle it appropriately. I don't see anything for Tomcat to do here. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.0.0-RC5: asynchron IO and back pressure with ReadListener
One option I am trying is to ignore onAllDataRead and to use sevletInputStream.isFinished to know when the body is totally consumed: https://github.com/yanns/servlet31_async/blob/master/src/main/java/com/yann/ReadListenerImpl.java#L55 Is it a dumb idea? 2014-03-20 7:42 GMT+01:00 Yann Simon yann.simon...@gmail.com: Thanks Rémy and Mark for the quick feedback and explanations! On Mar 19, 2014 6:40 PM, Mark Thomas ma...@apache.org wrote: On 19/03/2014 17:04, Rémy Maucherat wrote: 2014-03-19 17:47 GMT+01:00 Yann Simon yann.simon...@gmail.com: This is because you're forking a thread, it won't concurrently invoke the two events (which would be invalid). Can you explain more please? I have difficulties to understand your sentence. It means the container has to wait until onReadPossible completes to call onDataAvailable. I think Rémy meant Tomcat waits for onReadPossible() to complete before calling onAllDataRead() If you look at the traces from the sample code, you'll see that the onDataAvailable end message always appears before onAllDataRead which is all you can rely on. You are seeing slightly odd behaviour because you are spawning a new thread to do the read. If you do that you have to handle the case that your new thread may trigger the onAllDataRead event and handle it appropriately. I don't see anything for Tomcat to do here. 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: 回复： tomcat 5 logs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
改变自己,
On 3/20/14, 12:30 AM, 改变自己 wrote:
the source of my problem is that in the application ,we just used
many system.out sentence as a log output instead of using log4j,
because it is really a old applicaiton ; now we need to capture
the the system.out information as a log;
You should take a look at the swallowOutput setting for your
Context element. You can find documentation about it here:
https://tomcat.apache.org/tomcat-5.5-doc/config/context.html
Setting swallowOutput=true will cause System.out and System.err
within the application to be routed to the context-logger, which you
should be able to redirect to a rotatable log file.
To configure the context logger, edit Tomcat's conf/logging.properties
file. There should already be some configuration like this:
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/manager].level
= INFO
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/manager].handlers
= 3manager.org.apache.juli.FileHandler
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/host-manager].level
= INFO
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/host-manager].handlers
= 4host-manager.org.apache.juli.FileHandler
These lines configure loggers for specific applications: the first
pair of lines set up the logger for the manager application while
the second pair configure those for the host-manager application.
To set up one for your own application, do the following:
Create a new handler (what actually writes to a file):
10my-context-path.org.apache.juli.FileHandler.level = FINE
10my-context-path.org.apache.juli.FileHandler.directory =
${catalina.base}/logs
10my-context-path.org.apache.juli.FileHandler.prefix = my-context-path.
Configure the context to write to the handler:
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/my-context-path].handler=10my-context-path-handler.org.apache.juli.FileHandler
Set the logging level:
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/my-context-path].level=INFO
(or ERROR, WARN, FINE, FINEST, ALL)
The above, along with swallowOutput=true will take
System.out.println(Some log message) from your web application
deployed to /my-context-path and put it into
CATALINA_BASE/logs/my-context-path.[-MM-dd].log. The file should
be automatically rotated daily.
In case it's not obvious, the my-context-path text above should be
replaced with whatever your webapp's context path actually is. You can
call the log filename anything you want, and you can name the logger
(almost) anything you want -- check the documentation[1] -- but the
line with the [Catalina].[localhost].[/my-context-path] must match
your Service/Host/Context names (note the leading '/' in the context
path in the final portion of the logger name).
Finally, you should really upgrade. Tomcat 5 has been retired quite
some time ago, and Tomcat 6 will be considered for the chopping block
once Tomcat 8 is released. Fortunately, all of the above logging
configuration is available in Tomcat 5.5, 6.0, 7.0, and 8.0 so it
should still work for you if you upgrade.
Good luck,
- -chris
[1]
https://tomcat.apache.org/tomcat-5.5-doc/logging.html#java.util.logging
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJTKvb9AAoJEBzwKT+lPKRYTKwQALKn+WqCHpEZpR6u4xt78cL3
wGceVd5nofSO0AK5A+FWFp80BhMWtucObmk11F4ZkasaLokFxQxmscA6UZt6pT7+
GCgM65R9uNvUqf15c/rL6KytKpI2mXvQRc4I+/HCIwZnELIu0+2j1BVoZsrB0Ms6
rBetukD/pHdWub5lPQGmOlgwt0tlb6Yam93+h9KpAd1CZLmpAHIY6pVZeDcX1ZNC
j3MqMUspQxo0+SIH+RQ0MFwbWwsZ0aPM4rulGGXDJtlVQZNpcDeL94YbucC5Remt
yDnmWQOuAZ/tyXsbbAfZWLRMtAEftMEsdFnYXDqXSKv71Un6NpoLOUvsSMqHYuyh
+IgiOqkpNiZUjQdJPztXZNFxOZWtlGJd3A60NGWU+5X2ZnDRfJ4dbCTBHsEFG4Fy
I/YIYhQQFuEj3ANsfpTjBSRhPtpeVlR65CUcReSEaM9hkDs4DKS2HLt15gzUSUIa
vRFoALkihS7esqrjhd+/Rexy/loz8kGX2tqGchj8DgENO2XL6FG/9QCu6p/Wv6kc
XXVsRKBkImE45YrVqjFnQNmjDhvckXr6nL/9lKE0gOkWWPneiDu3KXK0Vb3qFtf0
ASW7nC/umCOgdm5ERyGQhYm4Jry5Lco76BaUfSvtz9lFpMaiyk3yjunNVvcG/qVe
YiQQU321q/pgARYMHoMH
=5dC/
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Trouble registering an MBean with mbeans-descriptors.xml
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 All, On 3/19/14, 12:24 PM, Christopher Schultz wrote: All, I'm trying to write my own MBean, and I have it working: the bean is registered and I can browse it using jconsole, etc., call methods, etc. At one point during the process, I believe I had the beans-descriptors.xml file actually being loaded, so that my customized descriptions of attributes and methods were being shown in jconsole. At some point, I changed something and they are no longer showing up. It looks like I'm getting an introspected MBean description instead of the declared one I want. All the attributes for example are described as Attribute exposed for management. I've set org.apache.tomcat.util.modeler.level=ALL and the same for the Console logger, so I'm getting a steady stream of output from the modeler package, including a whole bunch of messages like this: FINER [main] org.apache.tomcat.util.modeler.Registry.loadDescriptors Finding descriptor org/apache/catalina/authenticator Great. What I don't see is a similar message for my own MBean. It doesn't look like Tomcat is ever trying to load the mbeans-descriptors.xml file for my MBean. Here's what I've got: 0. Tomcat 8.0-trunk 1. A JAR file in CATALINA_BASE/lib containing my MBean interface, class, and mbeans-descriptors.xml, all in the same package (imaginatively called mbeans), and a Filter class that creates the bean and registers it with the MBean server. 2. The Tomcat examples webapp, with modifications to WEB-INF/web.xml to load the aforementioned Filter. Here's the whole mbeans-descriptors.xml file: ?xml version=1.0? mbeans-descriptors mbean name=RequestStats className=org.apache.catalina.mbeans.ClassNameMBean description=Server statistics and configuration domain=Catalina type=mbeans.RequestStats attribute name=className description=Fully qualified class name of the managed object type=java.lang.String writeable=false/ operation name=getProcessingTime description=Gets the total number of milliseconds spent processing requests. impact=INFO returnType=long /operation operation name=getRequestCount description=Gets the total number of requests processed. impact=INFO returnType=long /operation operation name=resetCounters description=Resets all counters. impact=ACTION returnType=void /operation /mbean /mbeans-descriptors I realize that two of the operations should probably be attributes instead, but it was about the time I changed from operation to attribute that things stopped working, so I rolled-back my changes a bit to back-track. Here's the contents of my mbean-example.jar file: Archive: mbeans-example.jar Length MethodSize Ratio Date Time CRC-32Name -- --- - -- 0 Stored0 0% 03-19-14 12:19 META-INF/ 103 Defl:N 90 13% 03-19-14 12:19 d2b59077 META-INF/MANIFEST.MF 0 Stored0 0% 03-19-14 11:57 filters/ 0 Stored0 0% 03-19-14 11:57 mbean/ 2387 Defl:N 1196 50% 03-19-14 12:19 2d7e415d filters/RequestStatsFilter.class 714 Defl:N 436 39% 03-19-14 11:57 7bdf9245 mbean/RequestStats.class 165 Defl:N 138 16% 03-19-14 11:57 041e1c7f mbean/RequestStatsMBean.class 1058 Defl:N 390 63% 03-19-14 12:19 ba6ca9b6 mbean/mbeans-descriptors.xml I can't see to find the text mbean.Request anywhere in the log files. I've become desperate and set org.apache.tomcat.level=ALL and org.apache.catalina.level=ALL to see if I can find anything. Setting the log level to ALL shows no attempt to even locate my mbeans-descriptors.xml file. Any pointers for where I can start looking? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTKveiAAoJEBzwKT+lPKRYd+MQAJ/9UfsMatOnKlvsuJV+M4Cb nJdYj9o7Na7GLjsP1nYTaCv95vqj+IlFhsCGZ4GH4VCp4ffBPBRD7kijcn+VUORn pzfzbDP4qYLzM03SqTDNsx0Xk3mafd7ZppXqm+tYYy6h5IJNq+v+nN3K9SAThYhb OcD7FWAeCc0CdBQT57VQesRQggMzCg+bVmFNBLC8dEwQ7BWx1Lh9PNybASQN7jjG 26KmmpGExOnj7pVHlBCS9bkuEuUOR1R2B4lsKTLNniaPW9AznKNdgziPxa7FhXCr FWauW/yb0LmRFvSnHDhN+zTzHwcOK/qnKTf2dR3J2alsBPJs37e93q0jo+o/f4+q rurDaSsYCkVckhhaGW4kiijMiXgdp2o6F0mMpId3AwGa/jqbQdfo8KqoQLz1Wcuq D86fGX/WJdwwuZorkAvCBCP1ttU7xhFwbzBVE8VDHf+nDiA4Ggp1KBFQ3o7PRYWu QD/7jqOiVNkiTBZomWIlgn5J2K8M8wgNlw1nRiSmLc64WFDRFGFNN3y4Va9qwX0F 6lIqtF01/X5iI2i4LsjKrfWK40OuVuqMyze5wJziLj6x5FTnjiAHie5afUQn3Jwb o+W+5L9qL5WKQMEHS+yO/O/u/8McFg9JTDXE7hHOlGNJQM2AMmUWp5k+toxPCewL 9CJt+D/n+N2LPkJ/cege =H4+B -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
?????? ?????? tomcat 5 logs
thank you very much for your detailed explanation ,
now i just resolved it with another way,
i used a cronlog.exe which is a executable file and can be used for produce
daily files;
and other configration is the same as my primary way.
thank you all the same!
best regards
-- --
??: Christopher Schultz;ch...@christopherschultz.net;
: 2014??3??20??(??) 10:11
??: Tomcat Users Listusers@tomcat.apache.org;
: Re: ?? tomcat 5 logs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
,
On 3/20/14, 12:30 AM, wrote:
the source of my problem is that in the application ,we just used
many system.out sentence as a log output instead of using log4j,
because it is really a old applicaiton ; now we need to capture
the the system.out information as a log;
You should take a look at the swallowOutput setting for your
Context element. You can find documentation about it here:
https://tomcat.apache.org/tomcat-5.5-doc/config/context.html
Setting swallowOutput=true will cause System.out and System.err
within the application to be routed to the context-logger, which you
should be able to redirect to a rotatable log file.
To configure the context logger, edit Tomcat's conf/logging.properties
file. There should already be some configuration like this:
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/manager].level
= INFO
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/manager].handlers
= 3manager.org.apache.juli.FileHandler
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/host-manager].level
= INFO
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/host-manager].handlers
= 4host-manager.org.apache.juli.FileHandler
These lines configure loggers for specific applications: the first
pair of lines set up the logger for the manager application while
the second pair configure those for the host-manager application.
To set up one for your own application, do the following:
Create a new handler (what actually writes to a file):
10my-context-path.org.apache.juli.FileHandler.level = FINE
10my-context-path.org.apache.juli.FileHandler.directory =
${catalina.base}/logs
10my-context-path.org.apache.juli.FileHandler.prefix = my-context-path.
Configure the context to write to the handler:
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/my-context-path].handler=10my-context-path-handler.org.apache.juli.FileHandler
Set the logging level:
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/my-context-path].level=INFO
(or ERROR, WARN, FINE, FINEST, ALL)
The above, along with swallowOutput=true will take
System.out.println(Some log message) from your web application
deployed to /my-context-path and put it into
CATALINA_BASE/logs/my-context-path.[-MM-dd].log. The file should
be automatically rotated daily.
In case it's not obvious, the my-context-path text above should be
replaced with whatever your webapp's context path actually is. You can
call the log filename anything you want, and you can name the logger
(almost) anything you want -- check the documentation[1] -- but the
line with the [Catalina].[localhost].[/my-context-path] must match
your Service/Host/Context names (note the leading '/' in the context
path in the final portion of the logger name).
Finally, you should really upgrade. Tomcat 5 has been retired quite
some time ago, and Tomcat 6 will be considered for the chopping block
once Tomcat 8 is released. Fortunately, all of the above logging
configuration is available in Tomcat 5.5, 6.0, 7.0, and 8.0 so it
should still work for you if you upgrade.
Good luck,
- -chris
[1]
https://tomcat.apache.org/tomcat-5.5-doc/logging.html#java.util.logging
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJTKvb9AAoJEBzwKT+lPKRYTKwQALKn+WqCHpEZpR6u4xt78cL3
wGceVd5nofSO0AK5A+FWFp80BhMWtucObmk11F4ZkasaLokFxQxmscA6UZt6pT7+
GCgM65R9uNvUqf15c/rL6KytKpI2mXvQRc4I+/HCIwZnELIu0+2j1BVoZsrB0Ms6
rBetukD/pHdWub5lPQGmOlgwt0tlb6Yam93+h9KpAd1CZLmpAHIY6pVZeDcX1ZNC
j3MqMUspQxo0+SIH+RQ0MFwbWwsZ0aPM4rulGGXDJtlVQZNpcDeL94YbucC5Remt
yDnmWQOuAZ/tyXsbbAfZWLRMtAEftMEsdFnYXDqXSKv71Un6NpoLOUvsSMqHYuyh
+IgiOqkpNiZUjQdJPztXZNFxOZWtlGJd3A60NGWU+5X2ZnDRfJ4dbCTBHsEFG4Fy
I/YIYhQQFuEj3ANsfpTjBSRhPtpeVlR65CUcReSEaM9hkDs4DKS2HLt15gzUSUIa
vRFoALkihS7esqrjhd+/Rexy/loz8kGX2tqGchj8DgENO2XL6FG/9QCu6p/Wv6kc
XXVsRKBkImE45YrVqjFnQNmjDhvckXr6nL/9lKE0gOkWWPneiDu3KXK0Vb3qFtf0
ASW7nC/umCOgdm5ERyGQhYm4Jry5Lco76BaUfSvtz9lFpMaiyk3yjunNVvcG/qVe
YiQQU321q/pgARYMHoMH
=5dC/
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
.
Re: Tomcat 8.0.0-RC5: asynchron IO and back pressure with ReadListener
Thanks for all your input, I think I have now an implementation that works on Tomcat and Jetty. By testing it, I've found something that can be an interesting information for you. The upload variant with forking a new thread is very very slow. My non scientific tests by uploading a file from 1.4 GB: - with tomca 8.0.3: /upload2: 4.5 s /upload (with new Thread): 2 mn - with jetty 9.1: /upload2: 3.6 s /upload (with new Thread): 4.1 s I tested it by removing all Thread.sleep from https://github.com/yanns/servlet31_async/blob/master/src/main/java/com/yann/ReadListenerImpl.java#L24 Cheers, Yann 2014-03-20 9:36 GMT+01:00 Yann Simon yann.simon...@gmail.com: One option I am trying is to ignore onAllDataRead and to use sevletInputStream.isFinished to know when the body is totally consumed: https://github.com/yanns/servlet31_async/blob/master/src/main/java/com/yann/ReadListenerImpl.java#L55 Is it a dumb idea? 2014-03-20 7:42 GMT+01:00 Yann Simon yann.simon...@gmail.com: Thanks Rémy and Mark for the quick feedback and explanations! On Mar 19, 2014 6:40 PM, Mark Thomas ma...@apache.org wrote: On 19/03/2014 17:04, Rémy Maucherat wrote: 2014-03-19 17:47 GMT+01:00 Yann Simon yann.simon...@gmail.com: This is because you're forking a thread, it won't concurrently invoke the two events (which would be invalid). Can you explain more please? I have difficulties to understand your sentence. It means the container has to wait until onReadPossible completes to call onDataAvailable. I think Rémy meant Tomcat waits for onReadPossible() to complete before calling onAllDataRead() If you look at the traces from the sample code, you'll see that the onDataAvailable end message always appears before onAllDataRead which is all you can rely on. You are seeing slightly odd behaviour because you are spawning a new thread to do the read. If you do that you have to handle the case that your new thread may trigger the onAllDataRead event and handle it appropriately. I don't see anything for Tomcat to do here. 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: HttpServletRequest Tomcat 5.5.29 to 7.0.52
I think I have fixed the error I had. I have downgraded to Java 6 update 45,
to see if it worked on there, but it didn't.
I stayed with Java 6 to try and resolve the issue. Basically in my
WEB-INF/web.xml file I have the following:
filter-mapping
filter-nameAuth Filter/filter-name
url-pattern*.jsp/url-pattern
url-pattern*.do/url-pattern
dispatcherREQUEST/dispatcher
/filter-mapping
All requests go to the doFilter() function. In Java 5.5.29 it wasn't sending
.jsp requests to the the doFilter, even though the above is in the web.xml file.
In Java 6 and above, it sends the .jsp file to be processed as well. So if I
comment out or take out the url-pattern*.jsp/url-pattern line, my code
works.
I don't know what's changed in the Java 6 code for this to not work.
Does anyone know why this is so I have an understanding of it?
Thanks again to all that have helped with this, I know I threw out multiple
questions, just didn't want to leave anything out :)
Seema
From: mgai...@hotmail.com
To: users@tomcat.apache.org
Subject: RE: HttpServletRequest Tomcat 5.5.29 to 7.0.52
Date: Tue, 18 Mar 2014 21:18:37 -0400
Seema-
You've asked about 10 different questions on 10 different aberrancies on your
upgrade
zip up the whole project up and stick it on driveway or any other free site
That way anyone building/running the code on TC7.0.52 can at least observe
same behaviour you are experiencing
Martin --
From: seema...@hotmail.com
To: users@tomcat.apache.org
Subject: RE: HttpServletRequest Tomcat 5.5.29 to 7.0.52
Date: Tue, 18 Mar 2014 14:10:19 +
Any update on this Chris Schultz or anyone else? I know the images I added
to the email didn't show up, so if you want me to email them directly to
you, I can.
Could really do with help on this, as it is not something I know much about.
Thanks
Seema
From: seema...@hotmail.com
To: users@tomcat.apache.org
Subject: RE: HttpServletRequest Tomcat 5.5.29 to 7.0.52
Date: Fri, 14 Mar 2014 15:15:04 +
Date: Fri, 14 Mar 2014 08:36:08 -0400
From: ch...@christopherschultz.net
To: users@tomcat.apache.org
Subject: Re: HttpServletRequest Tomcat 5.5.29 to 7.0.52
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Seema,
On 3/14/14, 7:53 AM, Seema Patel wrote:
I have upgraded my tomcat (5.5.29 to 7.0.52) and Java (1.5 to 1.7)
for my struts servlet jsp application. I have also removed all
JCIFS authentication from the WEB-INF/web.xml file and have tried
to do BASIC authentication through Tomcat and the AD (it
authenticates me, but not sure if I've missed anything out, as I've
never done this before).
One question at a time, please ;)
Sorry for the off-loading of multiple questions :-)
I have a doFilter function in my code, which contains
httpServletRequest.getServletPath() call. In the Tomcat 5.5.29 Java
1.5 version, this will work, as when I print
httpServletRequest.getServletPath() i get the following:
P1_00.do P5_0_0.do P5_0_1.do
But in Tomcat 7.0.52 Java 1.7 I get the following from
httpServletRequest.getServletPath() call:
P1_00.do P5_0_0.do P5_0_1.do includes/tab_defaultsettings.jsp
includes/P1_00.do
How are you printing this? Do you just have a Filter that wraps
everything and dumps-out the ServletPath for every request? Can you
post the code for that Filter as well as the filter and
filter-mapping configuration you have in web.xml?
I'm just doing a System.out.println() in the doFilter function in the
RequestFilter class to show which page it is. The doFilter function is:
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain) throws IOException, ServletException {
if (request instanceof HttpServletRequest) {
final HttpServletRequest httpRequest = (HttpServletRequest)request;
final Object userBeanObject =
httpRequest.getSession().getAttribute(GenConstants.LOGGED_IN_USER_BEAN);
final String pageName = httpRequest.getServletPath().replaceAll(/,);
System.out.println(Request Page = + httpRequest.getServletPath());
if (unsecuredPages.contains(pageName)) {
// don't need any protection
chain.doFilter(request, response);
} else if (!(userBeanObject instanceof UserBean)) {
// no user bean in session do need one, invalidate session and redirect
to login
if (httpRequest.getSession(false) != null) {
httpRequest.getSession().invalidate();
}
((HttpServletResponse)response).sendRedirect(logonPage);
} else {
final UserBean user = (UserBean) userBeanObject;
MapString,LogicalOperation permissions =
(MapString,LogicalOperation)context.getAttribute(GenConstants.PERMISSIONS_MAP);
if(permissions == null) {
PermissionsUtil.setupPermissions(context);
Server Tomcat v7.0 Server at localhost failed to start.
Hi Guys
Below are my log,my Tomcatv7 wont start.i tried to unstall and
reinstall the server but with no avail.any idea on this please?Tomcat just
says Server Tomcat v7.0 Server at localhost failed to start. And gives the
below error
---
Mar 20, 2014 11:53:59 AM org.apache.catalina.core.AprLifecycleListener init
INFO: The APR based Apache Tomcat Native library which allows optimal
performance in production environments was not found on the java.library.path:
C:\Program
Files\Java\jdk1.6.0_45\bin;C:\Windows\Sun\Java\bin;C:\Windows\system32;C:\Windows;C:\Program
Files (x86)\RSA SecurID Token
Common;O:\ora11202w\BIN;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Program
Files\Java\jdk1.6.0_45\bin;.exe;C:\Program Files (x86)\GNU\WinCvs
2.0\wincvs.exe;C:\Application\Maven-3.1.1\bin;C:\Application\groovy-2.2.0\bin;U:\PsGetsid;;.
Mar 20, 2014 11:54:00 AM org.apache.tomcat.util.net.AbstractEndpoint
adjustRelativePath
WARNING: configured
file:[C:/Application/jetty-distribution-9.0.3.v20130506/webapps/root/certificates/lsetmlocal]
does not exist.
Mar 20, 2014 11:54:00 AM org.apache.tomcat.util.digester.SetPropertiesRule begin
WARNING: [SetPropertiesRule]{Server/Service/Engine/Host/Context} Setting
property 'source' to 'org.eclipse.jst.j2ee.server:etm' did not find a matching
property.
Mar 20, 2014 11:54:00 AM org.apache.tomcat.util.digester.SetPropertiesRule begin
WARNING: [SetPropertiesRule]{Server/Service/Engine/Host/Context} Setting
property 'source' to 'org.eclipse.jst.jee.server:uverse' did not find a
matching property.
Mar 20, 2014 11:54:01 AM org.apache.coyote.AbstractProtocolHandler init
INFO: Initializing ProtocolHandler [http-bio-8080]
Mar 20, 2014 11:54:01 AM org.apache.coyote.AbstractProtocolHandler init
INFO: Initializing ProtocolHandler [http-bio-8443]
Mar 20, 2014 11:54:02 AM org.apache.tomcat.util.net.jsse.JSSESocketFactory
getStore
SEVERE: Failed to load keystore type JKS with path
C:/Application/jetty-distribution-9.0.3.v20130506/webapps/root/certificates/lsetmlocal
due to
C:\Application\jetty-distribution-9.0.3.v20130506\webapps\root\certificates\lsetmlocal
(The system cannot find the path specified)
java.io.FileNotFoundException:
C:\Application\jetty-distribution-9.0.3.v20130506\webapps\root\certificates\lsetmlocal
(The system cannot find the path specified)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.init(FileInputStream.java:120)
at
org.apache.tomcat.util.net.jsse.JSSESocketFactory.getStore(JSSESocketFactory.java:401)
at
org.apache.tomcat.util.net.jsse.JSSESocketFactory.getKeystore(JSSESocketFactory.java:307)
at
org.apache.tomcat.util.net.jsse.JSSESocketFactory.getKeyManagers(JSSESocketFactory.java:560)
at
org.apache.tomcat.util.net.jsse.JSSESocketFactory.getKeyManagers(JSSESocketFactory.java:506)
at
org.apache.tomcat.util.net.jsse.JSSESocketFactory.init(JSSESocketFactory.java:450)
at
org.apache.tomcat.util.net.jsse.JSSESocketFactory.createSocket(JSSESocketFactory.java:158)
at org.apache.tomcat.util.net.JIoEndpoint.bind(JIoEndpoint.java:365)
at
org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:482)
at
org.apache.coyote.AbstractProtocolHandler.init(AbstractProtocolHandler.java:354)
at
org.apache.coyote.http11.AbstractHttp11JsseProtocol.init(AbstractHttp11JsseProtocol.java:119)
at
org.apache.catalina.connector.Connector.initInternal(Connector.java:910)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:101)
at
org.apache.catalina.core.StandardService.initInternal(StandardService.java:559)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:101)
at
org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:781)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:101)
at org.apache.catalina.startup.Catalina.load(Catalina.java:572)
at org.apache.catalina.startup.Catalina.load(Catalina.java:595)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:262)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:430)
Mar 20, 2014 11:54:02 AM org.apache.coyote.AbstractProtocolHandler init
SEVERE: Failed to initialize end point associated with ProtocolHandler
[http-bio-8443]
java.io.FileNotFoundException:
C:\Application\jetty-distribution-9.0.3.v20130506\webapps\root\certificates\lsetmlocal
(The system cannot find
Re: Server Tomcat v7.0 Server at localhost failed to start.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Frank, On 3/20/14, 1:03 PM, Frank Lugalla wrote: INFO: Initializing ProtocolHandler [http-bio-8443] Mar 20, 2014 11:54:02 AM org.apache.tomcat.util.net.jsse.JSSESocketFactory getStore SEVERE: Failed to load keystore type JKS with path C:/Application/jetty-distribution-9.0.3.v20130506/webapps/root/certificates/lsetmlocal due to C:\Application\jetty-distribution-9.0.3.v20130506\webapps\root\certificates\lsetmlocal (The system cannot find the path specified) java.io.FileNotFoundException: C:\Application\jetty-distribution-9.0.3.v20130506\webapps\root\certificates\lsetmlocal (The system cannot find the path specified) at java.io.FileInputStream.open(Native Method) I'm guessing that you have a keystore configured that can't be read. Does that file exist? Is that the file you intended to set in your Connector configuration? Could you post said configuration (with passwords removed, please)? java.lang.UnsupportedClassVersionError: com/sbc/etm/servlet/EtmAdminServlet : Unsupported major.minor version 51.0 (unable to load class com.sbc.etm.servlet.EtmAdminServlet) at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:2822) This problem is easier to solve: you have compiled the com.sbc.etm.servlet package with a newer JDK than you are trying to run it under (e.g. compiled with Java 7 and you are running under Java 6). You have three options, here: 1. Run your code with the newer Java 2. Re-compile the code using the older Java 3. Re-compile your code in the newer Java, but with -target=older.java - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTKyDsAAoJEBzwKT+lPKRYtC4P/3fhR8iJiDdSDCMC17Defpl6 ZVk/ZFqxE3TpUovLRRE57VwlKJfzA5sPBdmMF+p6UGnH8o2esLUkDpwPRyHnfBwY Bb92vtYQRH0rSccCEr8gdD5GO59B3bvA3mQyC2Q7xHWMeDZSptxIh17o72NrxB/I vchhPyOFfcZGQIDioqGP1qWnXMWYk9hR9ek9tPm0d5LSuiXbzCeIsTq2P4z5fn2K KUrXOChnSezNjdnVPLzvWJ3qKGrNZ3Sis0fRHotuB7bnwQ3ipnw8VxsU4CofsxZl DxKjwkNqb8hkvulhAcrmw2DU3qUENn3VzokxFImoQfRv4HD8m7uKAYZCysyIRPo9 zxJqvZlk/U9Q5ObsqTvWAoimPJ1w4nyR5vBdkVhPnaT4yxKfN3I7sf5yhZobI1UX kN4y2NCSdnrwtS1CHkNgo0FUz75u6BsmC7tXo2lox6SrPlfabDLJ9AKC6cieqX+i qHWL1vpN89JmE0ORQcHz9dqBK7pYCT50OmpCf5a0VCCL28oUBMTcd1LvxIkFJgLK q/bhhgL6K6rCB2wXuzrI/Zk6fJLI7cxMBpy2vtD7NpTuKUzcwmJ7AsRYaws0ZeXJ bCg8eNGmLE+UZyO42IeBmkLFszFFK67DiJL6xCg1je6Kp12W/uDs3m6pPz8CdsWz EFaU/ijudxmL2Zm+nN3/ =UVp6 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: HttpServletRequest Tomcat 5.5.29 to 7.0.52
2014-03-20 20:55 GMT+04:00 Seema Patel seema...@hotmail.com: I think I have fixed the error I had. I have downgraded to Java 6 update 45, to see if it worked on there, but it didn't. I stayed with Java 6 to try and resolve the issue. Basically in my WEB-INF/web.xml file I have the following: filter-mapping filter-nameAuth Filter/filter-name url-pattern*.jsp/url-pattern url-pattern*.do/url-pattern dispatcherREQUEST/dispatcher /filter-mapping All requests go to the doFilter() function. In Java 5.5.29 it wasn't sending .jsp requests to the the doFilter, even though the above is in the web.xml file. In Java 6 and above, it sends the .jsp file to be processed as well. So if I comment out or take out the url-pattern*.jsp/url-pattern line, my code works. I don't know what's changed in the Java 6 code for this to not work. Does anyone know why this is so I have an understanding of it? Thanks again to all that have helped with this, I know I threw out multiple questions, just didn't want to leave anything out :) I guess s/Java/Tomcat/ in several places above. Support for multiple url-patterns did not exist in old versions of Servlet Specification, so only one of the patterns would work. Support for dispatcher also did not exist in old versions, but REQUEST is the default value here, so there is no difference. You can validate your web.xml file against DTD or schema it uses in any decent XML editor. (You can enable validation of web.xml in any version of Tomcat 7 and later. E.g., by setting org.apache.catalina.STRICT_SERVLET_COMPLIANCE=true http://tomcat.apache.org/tomcat-7.0-doc/config/systemprops.html#Specification When validation is enabled, Tomcat will refuse to deploy an application with broken web.xml ) Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: HttpServletRequest Tomcat 5.5.29 to 7.0.52
Date: Thu, 20 Mar 2014 21:12:09 +0400 Subject: Re: HttpServletRequest Tomcat 5.5.29 to 7.0.52 From: knst.koli...@gmail.com To: users@tomcat.apache.org 2014-03-20 20:55 GMT+04:00 Seema Patel seema...@hotmail.com: I think I have fixed the error I had. I have downgraded to Java 6 update 45, to see if it worked on there, but it didn't. I stayed with Java 6 to try and resolve the issue. Basically in my WEB-INF/web.xml file I have the following: filter-mapping filter-nameAuth Filter/filter-name url-pattern*.jsp/url-pattern url-pattern*.do/url-pattern dispatcherREQUEST/dispatcher /filter-mapping All requests go to the doFilter() function. In Java 5.5.29 it wasn't sending .jsp requests to the the doFilter, even though the above is in the web.xml file. In Java 6 and above, it sends the .jsp file to be processed as well. So if I comment out or take out the url-pattern*.jsp/url-pattern line, my code works. I don't know what's changed in the Java 6 code for this to not work. Does anyone know why this is so I have an understanding of it? Thanks again to all that have helped with this, I know I threw out multiple questions, just didn't want to leave anything out :) I guess s/Java/Tomcat/ in several places above. Support for multiple url-patterns did not exist in old versions of Servlet Specification, so only one of the patterns would work. Support for dispatcher also did not exist in old versions, but REQUEST is the default value here, so there is no difference. If dispatcher didn't exist and support for multiple url-patterns did not exist in older versions, then I don't know why the previous developers used it (I know this is nothing to do with you all). You can validate your web.xml file against DTD or schema it uses in any decent XML editor. My knowledge of all this isn't very good, could you please tell me what you mean by DTD or schema and could you give me an example of some XML editors I could use? Thanks (You can enable validation of web.xml in any version of Tomcat 7 and later. E.g., by setting org.apache.catalina.STRICT_SERVLET_COMPLIANCE=true http://tomcat.apache.org/tomcat-7.0-doc/config/systemprops.html#Specification When validation is enabled, Tomcat will refuse to deploy an application with broken web.xml ) Thanks for this, I'll set it and see what happens. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: WebSocket - very slow socket write (~15 min)
Hi- Any comments? I suspect an issue with the reliability of the timeout setting on Linux since the same behaves more reliably on Windows. In any case a 15 minute write to a socket with timeout setting of 20 seconds seems like a bug. Thanks On Wed, Mar 19, 2014 at 10:19 PM, Rossen Stoyanchev rstoyanc...@gopivotal.com wrote: hi, The scenario involves a mobile phone switching from wifi to (unstable) mobile network. The phone looses the connection but the server doesn't seem aware. Basically the server tries to send a message and blocks the thread on which this is done. From the logs it seems to take about 15 minutes before a java.net.SocketException: Broken pipe finally occurs. Is this expected behavior or an issue? I've seen the websocket-how-to on setting BLOCKING_SEND_TIMEOUT. However I would have expected a timeout based on the default value of 20 seconds. Also it says the property is configurable through the WebSocketSession but for something like this I would expect a global setting. Is there such a way to do that? The issue was originally reported here [1]. It's a long thread and might not add to much more. It's worth pointing out the issue seems to be reproducible with even 1 phone. Also it could not be reproduced on a windows server with the same tomcat7 server (7.0.52). Here is the stack of the the writing thread: - java.net.SocketOutputStream.socketWrite0(java.io.FileDescriptor, byte[], int, int) @bci=0 (Compiled frame; information may be imprecise) - java.net.SocketOutputStream.socketWrite(byte[], int, int) @bci=52, line=113 (Compiled frame) - java.net.SocketOutputStream.write(byte[], int, int) @bci=4, line=159 (Compiled frame) - org.apache.coyote.http11.upgrade.BioServletOutputStream.doWrite(boolean, byte[], int, int) @bci=8, line=37 (Compiled frame) - org.apache.coyote.http11.upgrade.AbstractServletOutputStream.writeInternal(byte[], int, int) @bci=24, line=125 (Compiled frame) - org.apache.coyote.http11.upgrade.AbstractServletOutputStream.write(byte[], int, int) @bci=16, line=92 (Compiled frame) - org.apache.tomcat.websocket.server.WsRemoteEndpointImplServer.onWritePossible(boolean) @bci=68, line=94 (Compiled frame) - org.apache.tomcat.websocket.server.WsRemoteEndpointImplServer.doWrite(javax.websocket.SendHandler, java.nio.ByteBuffer[]) @bci=12, line=81 (Compiled frame) - org.apache.tomcat.websocket.WsRemoteEndpointImplBase.writeMessagePart(org.apache.tomcat.websocket.WsRemoteEndpointImplBase$MessagePart) @bci=349, line=378 (Compiled frame) - org.apache.tomcat.websocket.WsRemoteEndpointImplBase.startMessage(byte, java.nio.ByteBuffer, boolean, javax.websocket.SendHandler) @bci=99, line=279 (Compiled frame) - org.apache.tomcat.websocket.WsRemoteEndpointImplBase$TextMessageSendHandler.write() @bci=97, line=672 (Interpreted frame) - org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendPartialString(java.nio.CharBuffer, boolean) @bci=43, line=210 (Interpreted frame) - org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendPartialString(java.lang.String, boolean) @bci=13, line=185 (Interpreted frame) - org.apache.tomcat.websocket.WsRemoteEndpointBasic.sendText(java.lang.String, boolean) @bci=6, line=49 (Compiled frame) Rossen
Re: HttpServletRequest Tomcat 5.5.29 to 7.0.52
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Seems, On 3/20/14, 1:52 PM, Seema Patel wrote: Date: Thu, 20 Mar 2014 21:12:09 +0400 Subject: Re: HttpServletRequest Tomcat 5.5.29 to 7.0.52 From: knst.koli...@gmail.com To: users@tomcat.apache.org 2014-03-20 20:55 GMT+04:00 Seema Patel seema...@hotmail.com: I think I have fixed the error I had. I have downgraded to Java 6 update 45, to see if it worked on there, but it didn't. I stayed with Java 6 to try and resolve the issue. Basically in my WEB-INF/web.xml file I have the following: filter-mapping filter-nameAuth Filter/filter-name url-pattern*.jsp/url-pattern url-pattern*.do/url-pattern dispatcherREQUEST/dispatcher /filter-mapping All requests go to the doFilter() function. In Java 5.5.29 it wasn't sending .jsp requests to the the doFilter, even though the above is in the web.xml file. In Java 6 and above, it sends the .jsp file to be processed as well. So if I comment out or take out the url-pattern*.jsp/url-pattern line, my code works. I don't know what's changed in the Java 6 code for this to not work. Does anyone know why this is so I have an understanding of it? Thanks again to all that have helped with this, I know I threw out multiple questions, just didn't want to leave anything out :) I guess s/Java/Tomcat/ in several places above. Support for multiple url-patterns did not exist in old versions of Servlet Specification, so only one of the patterns would work. Support for dispatcher also did not exist in old versions, but REQUEST is the default value here, so there is no difference. If dispatcher didn't exist and support for multiple url-patterns did not exist in older versions, then I don't know why the previous developers used it (I know this is nothing to do with you all). You can validate your web.xml file against DTD or schema it uses in any decent XML editor. My knowledge of all this isn't very good, could you please tell me what you mean by DTD or schema and could you give me an example of some XML editors I could use? Thanks XML uses DTDs or Schemas for semantic validation. http://en.wikipedia.org/wiki/Document_type_definition http://en.wikipedia.org/wiki/XML_Schema_%28W3C%29 Your XML files should either have a !DOCTYPE at the top indicating which DTD to use for validation or an xmlns[:namespace] definition at the top to use for Schema validation. Example of DTD: !DOCTYPE mbeans-descriptors PUBLIC -//Apache Software Foundation//DTD Model MBeans Configuration File http://jakarta.apache.org/commons/dtds/mbeans-descriptors.dtd; (Note that the SYSTEM id above -- the URL -- actually does not point to a valid DTD, so it may not work. Tomcat's mbeans-descriptors.xml files do not actually declare any DTD, but this is the DTD to which those files are expected to adhere.) Example of Schema: web-app xmlns=http://java.sun.com/xml/ns/javaee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd; version=2.5 metadata-complete=true Many XML editors will already know how to validate as long as the definitions are in the files. Eclipse already does this, but sometimes it's just stupid and tells you there is no DTD/Schema even though there clearly is one. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTKzSdAAoJEBzwKT+lPKRYjVEP/3/sP9tCM/pL+7H7Ani8GKdk bYGCMbO08+VBVHr8eoU8dc33ScQ7jwqw86fGmvTjzJEtsZQyHtL1jkouTxiSMd9U Qsv/sZcnR/JlY9rixo4wO05Oh/pqX6QQ3QSlaKTvKYELS0dN2RFTRcHYfWB99tll wdHE5mgytreUG8wpURGjCroftQLvrw+NxlD1GqAL6x+tt9kScEe1skWO2E95QKjG 5VtabDQJusfPzjCA0vj4bRILJdFPf5q9hEpBumvqXoMC2pJbYXdLWCtTB8JbVRtn FKex92ygdZhnIhzVgjAFNNbc/QacXgwdT33FmhpLBeMm9ZVOhQWehLtRBu/Ugdni 6af60lU6ScGJ7cDZZS1uVvGdXsnlg3up9Fy9GXokHlI91GoBE5sar7BzdsA+OMzb At+evpXwuhbyiyDbumoqdLZFb7xIXur4diw04UeSIaFNJVUdtkF2VoOrNW0+8W/V vEzj0b2V5CPJTPgg3AIuuF//2r0FLdRSZMUVaF0/idneyujtH4o3Uc5jBWcVZqCU 2eDNuDVUdTXwUlwOmL6jgF4C8dC9REJ5Lw5A9scwiaFaXt+c70UCKIXfI0LCdBsT k19KaBjbyRJyb5u9qE2bQQBQETvz4iCTJ/lUj3GDVtnsjeoeQxzJx0AtzAgSyVL5 U+Gxnbt3JejhsCmkGfib =tcq7 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Trouble registering an MBean with mbeans-descriptors.xml
2014-03-19 20:24 GMT+04:00 Christopher Schultz ch...@christopherschultz.net: I'm trying to write my own MBean, and I have it working: the bean is registered and I can browse it using jconsole, etc., call methods, etc. At one point during the process, I believe I had the beans-descriptors.xml file actually being loaded, so that my customized descriptions of attributes and methods were being shown in jconsole. At some point, I changed something and they are no longer showing up. It looks like I'm getting an introspected MBean description instead of the declared one I want. All the attributes for example are described as Attribute exposed for management. I've set org.apache.tomcat.util.modeler.level=ALL and the same for the Console logger, so I'm getting a steady stream of output from the modeler package, including a whole bunch of messages like this: FINER [main] org.apache.tomcat.util.modeler.Registry.loadDescriptors Finding descriptor org/apache/catalina/authenticator Great. What I don't see is a similar message for my own MBean. It doesn't look like Tomcat is ever trying to load the mbeans-descriptors.xml file for my MBean. Here's what I've got: 0. Tomcat 8.0-trunk 1. A JAR file in CATALINA_BASE/lib containing my MBean interface, class, and mbeans-descriptors.xml, all in the same package (imaginatively called mbeans), and a Filter class that creates the bean and registers it with the MBean server. 2. The Tomcat examples webapp, with modifications to WEB-INF/web.xml to load the aforementioned Filter. Here's the whole mbeans-descriptors.xml file: 1. Does your web application start, at all? Does you filter start? 2. How exactly are you registering your MBean? Are you using Modeler API for that? (Registry.registerComponent()) 3. Maybe run with a debugger? ?xml version=1.0? mbeans-descriptors mbean name=RequestStats className=org.apache.catalina.mbeans.ClassNameMBean description=Server statistics and configuration domain=Catalina type=mbeans.RequestStats 4. I see that many mbeans have a group attribute. Yours does not have one. (Actually it seems that this attribute is optional and is ignored. There are no calls to ManagedBean.getGroup() except in ManagedBean.toString()). 5. I hope that you do not have the second copy of your jar inside of your webapp. So that it shadows the one in the lib/ directory. 6. Apparently many mbean descriptors are pre-loaded when Tomcat starts - in o.a.c.mbeans.MBeanUtils.createRegistry() Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
