from:"Violeta Georgieva"

400 Bad Request when there are no web applications deployed on Tomcat

2011-02-08 Thread Violeta Georgieva

Hi,
I have the following use case:
I have no web applications deployed on Tomcat. 
Nevertheless when I request a web application: http://localhost:8080/testapp
Instead of the expected 404 Not Found I'm receiving 400 Bad Request.
Can you explain why is that. Typically such response is returned in case the 
request cannot be fulfilled due to bad syntax.
Thanks
Regards
Violeta
 

-
Искаш нов телефон? Избери го оттук
http://ad.aukro.bg/listing.php/showcat?id=52474view=galst=gal

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: 400 Bad Request when there are no web applications deployed on Tomcat

2011-02-08 Thread Violeta Georgieva

Hi,
This scenario is working as expected on Tomcat 7.0.8, and not working as
expected on Tomcat 6.0.32.
I found the mail thread [1] but one of the proposed solutions there is to
deploy ROOT app which is not a solution for my system environment.
I created a bug report [2] with a proposal.
Regards
Violeta
[1] http://www.mail-archive.com/users@tomcat.apache.org/msg86160.html
[2] http://issues.apache.org/bugzilla/show_bug.cgi?id=50734

-Original Message-

I think there was another thread not long ago (2 months max) on the same
subject.
May be worth searching the archives.

It would also help if you provided an exact version of Tomcat.

Violeta Georgieva wrote:
Hi,
I have the following use case:
I have no web applications deployed on Tomcat.
Nevertheless when I request a web application:
http://localhost:8080/testapp
Instead of the expected 404 Not Found I'm receiving 400 Bad Request.
Can you explain why is that. Typically such response is returned in case
the request cannot be fulfilled due to bad syntax.
Thanks
Regards
Violeta

-
Искаш нов телефон? Избери го оттук
http://ad.aukro.bg/listing.php/showcat?id=52474view=galst=gal

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

-
Най-известните модни марки с до -70% само от Fashion Days!
http://clk.tradedoubler.com/click?p=191500a=1875689g=19425934

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Fwd: SessionListener.sessionDestroyed is not called when stopping web application

2011-10-10 Thread Violeta Georgieva

 Hi,

I have a web application that uses HttpSessionListener's methods for session
creation and destruction notifications.
When I request my web application I receive sessionCreated, when I
invalidate the session from the code I receive sessionDestroyed.
Unfortunately when I stop the web application I do not receive
sessionDestroyed.
I checked the code where StandardContext is stopped. I can see that
StandardManager.stop is called which is ok
But when StandardManager.doUnload() is invoked, in its implementation *
session.expire(false)* is called where the false is actually the flag that
indicates whether to notify the listeners or not. As it is invoked with
false - the listeners are not invoked.

I made a patch in StandardManager, when apply it to my system,
sessionDestroyed is called.

Could you check my proposal and tell whether my assumptions.

Thanks in advance

Best Regards

Violeta Georgieva

Environment details: Tomcat 6.0.33, Window 7

Patch



Index: StandardManager.java
===
--- StandardManager.java (revision 1181173)
+++ StandardManager.java (working copy)
@@ -565,7 +565,7 @@
 while (expires.hasNext()) {
 StandardSession session = (StandardSession) expires.next();
 try {
-session.expire(false);
+session.expire();
 } catch (Throwable t) {
 ;
 } finally {

Re: Fwd: SessionListener.sessionDestroyed is not called when stopping web application

2011-10-10 Thread Violeta Georgieva

Hi Chris,

I tried:
- stopping application
- undeploying application
- stopping Tomcat

I can confirm that in all three scenarios sessionDestroyed method is not
invoked and session.expire(false) is invoked.

Thanks
Violeta

2011/10/10 Christopher Schultz ch...@christopherschultz.net

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Violeta,

 On 10/10/2011 3:59 PM, Violeta Georgieva wrote:
  But when StandardManager.doUnload() is invoked, in its
  implementation * session.expire(false)* is called where the false
  is actually the flag that indicates whether to notify the listeners
  or not. As it is invoked with false - the listeners are not
  invoked.

 Are you undeploying the webapp or just stopping it?

 - -chris
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.10 (MingW32)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

 iEYEARECAAYFAk6TVQQACgkQ9CaO5/Lv0PAoLQCeO89VVJhMCsErKdFvt36fv4RX
 7ZEAoINWE9gcYK22Vrm5C1ltpm3Bj5ET
 =PoyT
 -END PGP SIGNATURE-

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Fwd: SessionListener.sessionDestroyed is not called when stopping web application

2011-10-10 Thread Violeta Georgieva

There is no cluster, just one instance of Tomcat
The scenarios are reproducible on Tomcat 6.0.32 and Tomcat 6.0.33

2011/10/11 Pid p...@pidster.com

 On 11/10/2011 06:24, Violeta Georgieva wrote:
  Hi Chris,
 
  I tried:
  - stopping application
  - undeploying application
  - stopping Tomcat
 
  I can confirm that in all three scenarios sessionDestroyed method is not
  invoked and session.expire(false) is invoked.

 Is your application deployed to a cluster of Tomcats?

 Which exact version of Tomcat are you using?


 p


  Thanks
  Violeta
 
  2011/10/10 Christopher Schultz ch...@christopherschultz.net
 
  Violeta,
 
  On 10/10/2011 3:59 PM, Violeta Georgieva wrote:
  But when StandardManager.doUnload() is invoked, in its
  implementation * session.expire(false)* is called where the false
  is actually the flag that indicates whether to notify the listeners
  or not. As it is invoked with false - the listeners are not
  invoked.
 
  Are you undeploying the webapp or just stopping it?
 
  -chris
  
  -
  To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
  For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Fwd: SessionListener.sessionDestroyed is not called when stopping web application

2011-10-11 Thread Violeta Georgieva

Hi Chuck,

I tried it and it is working.
As I understood this is the recommended way to do this, correct?

Thank you very much.
Regards
Violeta

2011/10/11 Caldarale, Charles R chuck.caldar...@unisys.com

  From: Violeta Georgieva [mailto:miles...@gmail.com]
  Subject: Re: Fwd: SessionListener.sessionDestroyed is not called when
 stopping web application

  I can confirm that in all three scenarios sessionDestroyed method
  is not invoked and session.expire(false) is invoked.

 This may be because the sessions are not actually destroyed.  Tomcat
 normally persists sessions in the work directory under the name
 Catalina/[host]/[appName]/SESSIONS.ser when it stops so that the sessions
 can be recovered when it restarts.  Look here for more info:


 http://tomcat.apache.org/tomcat-6.0-doc/config/manager.html#Restart%20Persistence

 If you want to disable session persistence, you can configure a Manager
 for the Context of interest, and set its pathname attribute to an empty
 string.


 http://tomcat.apache.org/tomcat-6.0-doc/config/manager.html#Standard_Implementation

  - 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

High memory consumption caused by BLOCKED Threads

2011-12-22 Thread Violeta Georgieva

Hi,

I am using Tomcat 6.0.29 and SUN JVM.
I experience high memory consumption caused by BLOCKED Threads.

I would appreciate any help or suggestion how to solve the problem.

I can see the following in the thread dump:


http-8080-73 daemon prio=10 tid=0x7ff9a4586000 nid=0x7d3 waiting for
monitor entry [0x7ff9996d4000]

   java.lang.Thread.State: BLOCKED (on object monitor)

   at
sun.util.resources.TimeZoneNames.getContents(TimeZoneNames.java:185)

   at
sun.util.resources.OpenListResourceBundle.loadLookup(OpenListResourceBundle.java:109)

   - locked 0x0006f95a49b8 (a
sun.util.resources.TimeZoneNames)

   at
sun.util.resources.OpenListResourceBundle.loadLookupTablesIfNecessary(OpenListResourceBundle.java:97)

   at
sun.util.resources.OpenListResourceBundle.handleGetObject(OpenListResourceBundle.java:58)

   at
sun.util.resources.TimeZoneNamesBundle.handleGetObject(TimeZoneNamesBundle.java:59)

   at
java.util.ResourceBundle.getObject(ResourceBundle.java:368)

   at
java.util.ResourceBundle.getObject(ResourceBundle.java:371)

   at
java.util.ResourceBundle.getStringArray(ResourceBundle.java:351)

   at
sun.util.TimeZoneNameUtility.retrieveDisplayNames(TimeZoneNameUtility.java:100)

   at
sun.util.TimeZoneNameUtility.retrieveDisplayNames(TimeZoneNameUtility.java:81)

   at java.util.TimeZone.getDisplayNames(TimeZone.java:399)

   at java.util.TimeZone.getDisplayName(TimeZone.java:350)

   at
java.text.SimpleDateFormat.subFormat(SimpleDateFormat.java:1110)

   at
java.text.SimpleDateFormat.format(SimpleDateFormat.java:899)

   at
java.text.SimpleDateFormat.format(SimpleDateFormat.java:869)

   at java.text.DateFormat.format(DateFormat.java:316)

   at
org.apache.tomcat.util.http.FastHttpDateFormat.getCurrentDate(FastHttpDateFormat.java:115)

   - locked 0x0006fbd04ee8 (a java.text.SimpleDateFormat)

   at
org.apache.coyote.http11.Http11Processor.prepareResponse(Http11Processor.java:1606)

   at
org.apache.coyote.http11.Http11Processor.action(Http11Processor.java:956)

   at org.apache.coyote.Response.action(Response.java:183)

   at org.apache.coyote.Response.sendHeaders(Response.java:379)

   at
org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:305)

   at
org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:273)

   at
org.apache.catalina.connector.Response.finishResponse(Response.java:493)

   at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:322)

   at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859)

   at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)

   at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)

   at java.lang.Thread.run(Thread.java:662)



Line 2485 :  - waiting to lock 0x0006fbd04ee8 (a
java.text.SimpleDateFormat)

Line 2536 :  - waiting to lock 0x0006fbd04ee8 (a
java.text.SimpleDateFormat)

Line 2625 :  - waiting to lock 0x0006fbd04ee8 (a
java.text.SimpleDateFormat)

Line 2660 :  - waiting to lock 0x0006fbd04ee8 (a
java.text.SimpleDateFormat)

Line 2703 :  - locked 0x0006fbd04ee8 (a
java.text.SimpleDateFormat)

Line 2741 :  - waiting to lock 0x0006fbd04ee8 (a
java.text.SimpleDateFormat)

Line 2758 :  - waiting to lock 0x0006fbd04ee8 (a
java.text.SimpleDateFormat)

Line 2775 :  - waiting to lock 0x0006fbd04ee8 (a
java.text.SimpleDateFormat)

Line 2792 :  - waiting to lock 0x0006fbd04ee8 (a
java.text.SimpleDateFormat)

Line 2848 :  - waiting to lock 0x0006fbd04ee8 (a
java.text.SimpleDateFormat)

Line 2865 :  - waiting to lock 0x0006fbd04ee8 (a
java.text.SimpleDateFormat)

Line 2891 :  - waiting to lock 0x0006fbd04ee8 (a
java.text.SimpleDateFormat)

Line 2908 :  - waiting to lock 0x0006fbd04ee8 (a
java.text.SimpleDateFormat)

Line 2925 :  - waiting to lock 0x0006fbd04ee8 (a
java.text.SimpleDateFormat)

Line 2942 :  - waiting to lock 0x0006fbd04ee8 (a
java.text.SimpleDateFormat)

Line 2959 :  - waiting to lock 0x0006fbd04ee8 (a
java.text.SimpleDateFormat)

Line 2976 :  - waiting to lock 0x0006fbd04ee8 (a
java.text.SimpleDateFormat)

Line 2993 :  - waiting to lock 0x0006fbd04ee8 (a
java.text.SimpleDateFormat)

Line 3010 :  - waiting to lock 0x0006fbd04ee8 (a
java.text.SimpleDateFormat)

Line 3027 :  - waiting to lock 0x0006fbd04ee8 (a
java.text.SimpleDateFormat)

Line 3044 :  - waiting to lock

Re: High memory consumption caused by BLOCKED Threads

2011-12-22 Thread Violeta Georgieva

The blocked threads that are waiting to get the lock, in order to finish
the response, are holding a lot of memory that they cannot release.
I have 50 blocked threads that are waiting.

2011/12/22 Mark Thomas ma...@apache.org

 On 22/12/2011 09:05, Violeta Georgieva wrote:
  Hi,
 
  I am using Tomcat 6.0.29 and SUN JVM.
  I experience high memory consumption caused by BLOCKED Threads.

 Blocked threads will not cause high memory consumption.

  I would appreciate any help or suggestion how to solve the problem.

 Try telling us what the real problem is rather than what you think the
 cause is.

 Mark

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

Re: High memory consumption caused by BLOCKED Threads

2011-12-22 Thread Violeta Georgieva

But I do not make locks on the SimpleDateFormat objects?

Tomcat does it while finishing the response.

Here is one of the threads that waits to lock:

http-8080-84 daemon prio=10 tid=0x7ff9a4340800 nid=0xf5d waiting for
monitor entry [0x7ff9990cf000]
   java.lang.Thread.State: BLOCKED (on object monitor)
 at
org.apache.tomcat.util.http.FastHttpDateFormat.getCurrentDate(FastHttpDateFormat.java:114)
 - waiting to lock 0x0006fbd04ee8 (a java.text.SimpleDateFormat)
 at
org.apache.coyote.http11.Http11Processor.prepareResponse(Http11Processor.java:1606)
 at
org.apache.coyote.http11.Http11Processor.action(Http11Processor.java:956)
 at org.apache.coyote.Response.action(Response.java:183)
 at org.apache.coyote.Response.sendHeaders(Response.java:379)
 at
org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:305)
 at org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:273)
 at org.apache.catalina.connector.Response.finishResponse(Response.java:493)
 at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:322)
 at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859)
 at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
 at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
 at java.lang.Thread.run(Thread.java:662)

2011/12/22 David kerber dcker...@verizon.net

 On 12/22/2011 4:05 AM, Violeta Georgieva wrote:

 Hi,

 I am using Tomcat 6.0.29 and SUN JVM.
 I experience high memory consumption caused by BLOCKED Threads.

 I would appreciate any help or suggestion how to solve the problem.


 Fix your app so that it releases the locks (probably synchronized
 sections) on the SimpleDateFormat objects.




 I can see the following in the thread dump:


 http-8080-73 daemon prio=10 tid=0x7ff9a4586000 nid=0x7d3 waiting for
 monitor entry [0x7ff9996d4000]

java.lang.Thread.State: BLOCKED (on object monitor)

at
 sun.util.resources.**TimeZoneNames.getContents(**TimeZoneNames.java:185)

at
 sun.util.resources.**OpenListResourceBundle.**loadLookup(**
 OpenListResourceBundle.java:**109)

- locked0x0006f95a49b8  (a
 sun.util.resources.**TimeZoneNames)

at
 sun.util.resources.**OpenListResourceBundle.**
 loadLookupTablesIfNecessary(**OpenListResourceBundle.java:**97)

at
 sun.util.resources.**OpenListResourceBundle.**handleGetObject(**
 OpenListResourceBundle.java:**58)

at
 sun.util.resources.**TimeZoneNamesBundle.**handleGetObject(**
 TimeZoneNamesBundle.java:59)

at
 java.util.ResourceBundle.**getObject(ResourceBundle.java:**368)

at
 java.util.ResourceBundle.**getObject(ResourceBundle.java:**371)

at
 java.util.ResourceBundle.**getStringArray(ResourceBundle.**java:351)

at
 sun.util.TimeZoneNameUtility.**retrieveDisplayNames(**
 TimeZoneNameUtility.java:100)

at
 sun.util.TimeZoneNameUtility.**retrieveDisplayNames(**
 TimeZoneNameUtility.java:81)

at java.util.TimeZone.**getDisplayNames(TimeZone.java:**
 399)

at java.util.TimeZone.**getDisplayName(TimeZone.java:**
 350)

at
 java.text.SimpleDateFormat.**subFormat(SimpleDateFormat.**java:1110)

at
 java.text.SimpleDateFormat.**format(SimpleDateFormat.java:**899)

at
 java.text.SimpleDateFormat.**format(SimpleDateFormat.java:**869)

at java.text.DateFormat.format(**DateFormat.java:316)

at
 org.apache.tomcat.util.http.**FastHttpDateFormat.**getCurrentDate(**
 FastHttpDateFormat.java:115)

- locked0x0006fbd04ee8  (a
 java.text.SimpleDateFormat)

at
 org.apache.coyote.http11.**Http11Processor.**prepareResponse(**
 Http11Processor.java:1606)

at
 org.apache.coyote.http11.**Http11Processor.action(**
 Http11Processor.java:956)

at org.apache.coyote.Response.**action(Response.java:183)

at org.apache.coyote.Response.**
 sendHeaders(Response.java:379)

at
 org.apache.catalina.connector.**OutputBuffer.doFlush(**
 OutputBuffer.java:305)

at
 org.apache.catalina.connector.**OutputBuffer.close(**
 OutputBuffer.java:273)

at
 org.apache.catalina.connector.**Response.finishResponse(**
 Response.java:493)

at
 org.apache.catalina.connector.**CoyoteAdapter.service(**
 CoyoteAdapter.java:322)

at
 org.apache.coyote.http11.**Http11Processor.process(**
 Http11Processor.java:859)

at
 org.apache.coyote.http11.**Http11Protocol$**Http11ConnectionHandler.**
 process(Http11Protocol.java:**588)

at
 org.apache.tomcat.util.net.**JIoEndpoint$Worker.run(**
 JIoEndpoint.java:489)

at java.lang.Thread.run(Thread.**java:662)



 Line 2485

Re: High memory consumption caused by BLOCKED Threads

2011-12-27 Thread Violeta Georgieva

Thanks to all of you!

I'm profiling the application now.

Happy New Year
Violeta

2011/12/23 Christopher Schultz ch...@christopherschultz.net

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Rainer,

 On 12/22/11 2:00 PM, Rainer Jung wrote:
  Hmmm, actually I had a short look at the code of
 
  sun.util.resources.TimeZoneNames.getContents(TimeZoneNames.java:185)
 
   and i don't unerstand why it is waiting for a monitor entry. The
  method should quickly return an array of objects which is
  explicitely defined in the class and that's it. No idea what's
  happening here.
 
  @Violeta: is anything wrong with your system, e.g. did you get an
  OutOfMemoryError somewhere? It looks your JVM is in a strange
  state. Are you doing frequent redeployments without stopping
  Tomcat?

 +1

 Looks like something horrible has happened in the JVM.

 - -chris
 -BEGIN PGP SIGNATURE-
 Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
 Comment: GPGTools - http://gpgtools.org
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

 iEYEARECAAYFAk7zskQACgkQ9CaO5/Lv0PDv2gCfUtQObYXhqNKH8LxEMT3rBuU5
 O0wAoKoCNwYv6a50LMTmv6y+cGRu+fAc
 =M07c
 -END PGP SIGNATURE-

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Caching of protected static content with Expires header: Expires Thu, 01 Jan 1970 03:00:00 EET?

2012-01-20 Thread Violeta Georgieva

And if I want to cache a protected resource only locally what I should do?

Thanks

2012/1/20 ma...@apache.org

 Violeta Georgieva violet...@apache.org wrote:

 Hi,
 
 If the static content is not protected then by default it is cached and
 the
 corresponding headers are set - see screenshot1  screenshot2.
 but when I put it as protected content the following headers are set:
 Cache-control:private and Expires header: Expires Thu, 01 Jan 1970
 03:00:00
 EET - see screenshot3  screenshot4
 My question is why the expires header is set with this value? Doesn't
 this
 prevent caching?

 Yes. That is the point.

 Mark


 
 I'm running Tomcat 7.0.23
 
 Thanks in advance
 Regards
 Violeta
 
  -
 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: Dependencies on extensions functionality

2012-02-04 Thread Violeta Georgieva

Hi,

The Dependencies on Extensions mechanism is described in Servlet Spec 3.0 -
chapter 10.7.1.

In the web application's Manifest file one should describe the following:

Extension-List: extension
extension-Extension-Name: name
extension-Specification-Version: version
extension-Implementation-Version: version
extension-Implementation-Vendor-Id: vendor

in the jar file's Manifest (this is the extension), one should specify:

Extension-Name: name
Specification-Version: version
Implementation-Version: version
Implementation-Vendor-Id: vendor


So from the spec we have The container must provide a directory for these
libraries. The files placed within this directory must be available across
all Web applications. The location of this directory is container-specific.
The class loader the servlet container uses for loading these library files
must be the same for all Web applications within the same JVM. This class
loader instance must be somewhere in the chain of parent class loaders of
the Web application class loader.

From Tomcat sources I can see that while starting web app context
(StandardContext.startInternal()) the extensions are checked for
availability (ExtensionValidator.validateApplication). I can see again in
the ExtensionValidator that catalina.ext.dirs also is scanned while
scanning for container level extensions. Unfortunately I cannot find a
place where this extensions are made available for web applications.


Regards
Violeta

2012/2/3 Pid p...@pidster.com

 On 03/02/2012 13:25, Violeta Georgieva wrote:
  Hi,
 
  I'm using Tomcat 7.0.23 on Windows.
 
  I have a web application that specifies in the Manifest that wants to use
  an extension.

 How does it do that?

  I specify catalina.ext.dirs to point to the directory where I placed my
  extensions jar files.

 How is that property processed?


  Unfortunately when I request my application I'm receiving
  ClassNotFoundException.
 
  I verified that
 
  ExtensionValidator.validateApplication() succeeded to find the extension
  jar file.
 
  What could be the problem? May be I'm missing some configuration?

 No idea.  What are extensions?

 How is that JAR file added to the/a classloader?


 p


  Thanks in advance.
 
  Regards
 
  Violeta
 


 --

 [key:62590808]

Re: Dependencies on extensions functionality

2012-02-04 Thread Violeta Georgieva

Hi,

Here is how one can reproduce the scenario:

1. Start Tomcat
2. Put attached war in webapps folder
3. In the console the following error message is printed:

INFO: Deploying web application archive
C:\apache-tomcat-7.0.25\webapps\test-web-app.war
Feb 4, 2012 10:41:44 PM org.apache.catalina.util.ExtensionValidator
validateManifestResources
INFO: ExtensionValidator[/test-web-app][Web Application Manifest]: Required
extension [test-jar] not found.
Feb 4, 2012 10:41:44 PM org.apache.catalina.util.ExtensionValidator
validateManifestResources
INFO: ExtensionValidator[/test-web-app]: Failure to find [1] required
extension(s).
Feb 4, 2012 10:41:44 PM org.apache.catalina.core.StandardContext
startInternal
SEVERE: Error getConfigured
Feb 4, 2012 10:41:44 PM org.apache.catalina.core.StandardContext
startInternal
SEVERE: Context [/test-web-app] startup failed due to previous errors

4. Stop Tomcat
5. Create folder - C:\apache-tomcat-7.0.25\ext
6. Put the attached jar file in the folder created on step 5
7. Start Tomcat with additional VM argument
-Dcatalina.ext.dirs=C:/apache-tomcat-7.0.25/ext
8. This time the application is deployed successfully.
9. Request http://localhost:8080/test-web-app/TestServlet
10. Internal Server Error is returned with the following Exception:


java.lang.ClassNotFoundException: test.TestExtension

org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1701)

org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1546)
test.TestServlet.doGet(TestServlet.java:28)
javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
javax.servlet.http.HttpServlet.service(HttpServlet.java:722)

I did not change any other Tomcat configuration so it is running with
defaults.

The scenario is that TestServlet (in war file) instantiates TestExtension
(in jar file, placed in the ext directory).

Regards
Violeta
2012/2/4 Christopher Schultz ch...@christopherschultz.net

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Violetta,

 On 2/3/12 8:25 AM, Violeta Georgieva wrote:
  I have a web application that specifies in the Manifest that wants
  to use an extension.
 
  I specify catalina.ext.dirs to point to the directory where I
  placed my extensions jar files.

 What is the value of the catalina.ext.dirs system property? Where did
 you set it? Can you verify that it is set when the JVM actually starts?

 What files are in the directory or directories specified by
 catalina.ext.dir?

  Unfortunately when I request my application I'm receiving
  ClassNotFoundException.

 What class cannot be found? Is it found in any of the JAR files you
 have in your catalina.ext.dir (which is, of course, the whole point of
 the feature)?

  I verified that
 
  ExtensionValidator.validateApplication() succeeded to find the
  extension jar file.

 How did you verify this? Are there logs that suggest your JAR file is
 being scanned? Please provide them.

  What could be the problem? May be I'm missing some configuration?

 You might be, but you haven't provided any configuration to us, so we
 don't know if you're missing something. Clearly, something is
 misconfigured.

 - -chris
 -BEGIN PGP SIGNATURE-
 Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
 Comment: GPGTools - http://gpgtools.org
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

 iEYEARECAAYFAk8tdnIACgkQ9CaO5/Lv0PCjtQCgkh8h231IQe4SZjkz2J0VzQh1
 r3IAnidzPXJfRdV1TEu3b+qf0jiplsfA
 =Lv/W
 -END PGP SIGNATURE-

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org




test-jar.jar
Description: application/java-archive

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Dependencies on extensions functionality

2012-02-05 Thread Violeta Georgieva

here is a link to the attached example

https://docs.google.com/open?id=0B-HUwAvkRIKJZTNhMDE1ZjEtY2M0Yy00YjZkLWE4NjktYjAwZWIzMzU2NzQw

2012/2/5 Casper Wandahl Schmidt kalle.pri...@gmail.com

Den 05-02-2012 08:18, Violeta Georgieva skrev:

I'm attaching again the examples cause I think that one of them was not
attached very well.

The list strips attachments so you need to upload the files somewhere (eg.
rapidshare) and give us a link to download it :)

2012/2/4 Violeta Georgieva miles...@gmail.com mailto:miles...@gmail.com

Hi,
Here is how one can reproduce the scenario:
1. Start Tomcat
2. Put attached war in webapps folder
3. In the console the following error message is printed:
INFO: Deploying web application archive
C:\apache-tomcat-7.0.25\**webapps\test-web-app.war
Feb 4, 2012 10:41:44 PM
org.apache.catalina.util.**ExtensionValidator
validateManifestResources
INFO: ExtensionValidator[/test-web-**app][Web Application Manifest]:
Required extension [test-jar] not found.
Feb 4, 2012 10:41:44 PM
org.apache.catalina.util.**ExtensionValidator
validateManifestResources
INFO: ExtensionValidator[/test-web-**app]: Failure to find [1]
required extension(s).
Feb 4, 2012 10:41:44 PM org.apache.catalina.core.**StandardContext
startInternal
SEVERE: Error getConfigured
Feb 4, 2012 10:41:44 PM org.apache.catalina.core.**StandardContext
startInternal
SEVERE: Context [/test-web-app] startup failed due to previous errors
4. Stop Tomcat
5. Create folder - C:\apache-tomcat-7.0.25\ext
6. Put the attached jar file in the folder created on step 5
7. Start Tomcat with additional VM argument
-Dcatalina.ext.dirs=C:/apache-**tomcat-7.0.25/ext
8. This time the application is deployed successfully.
9. Request
http://localhost:8080/test-**web-app/TestServlethttp://localhost:8080/test-web-app/TestServlet
10. Internal Server Error is returned with the following Exception:

java.lang.**ClassNotFoundException: test.TestExtension
org.apache.catalina.loader.**WebappClassLoader.loadClass(**
WebappClassLoader.java:1701)
org.apache.catalina.loader.**WebappClassLoader.loadClass(**
WebappClassLoader.java:1546)
test.TestServlet.doGet(**TestServlet.java:28)
javax.servlet.http.**HttpServlet.service(**HttpServlet.java:621)
javax.servlet.http.**HttpServlet.service(**HttpServlet.java:722)

I did not change any other Tomcat configuration so it is running
with defaults.
The scenario is that TestServlet (in war file) instantiates
TestExtension (in jar file, placed in the ext directory).
Regards
Violeta
2012/2/4 Christopher Schultz ch...@christopherschultz.net
mailto:chris@**christopherschultz.net ch...@christopherschultz.net

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Violetta,

On 2/3/12 8:25 AM, Violeta Georgieva wrote:
I have a web application that specifies in the Manifest that
wants
to use an extension.

I specify catalina.ext.dirs to point to the directory where I
placed my extensions jar files.

What is the value of the catalina.ext.dirs system property?
Where did
you set it? Can you verify that it is set when the JVM
actually starts?

What files are in the directory or directories specified by
catalina.ext.dir?

Unfortunately when I request my application I'm receiving
ClassNotFoundException.

What class cannot be found? Is it found in any of the JAR
files you
have in your catalina.ext.dir (which is, of course, the whole
point of
the feature)?

I verified that

ExtensionValidator.**validateApplication() succeeded to find the
extension jar file.

How did you verify this? Are there logs that suggest your JAR
file is
being scanned? Please provide them.

What could be the problem? May be I'm missing some
configuration?

You might be, but you haven't provided any configuration to
us, so we
don't know if you're missing something. Clearly, something is
misconfigured.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org http://gpgtools.org/

Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk8tdnIACgkQ9CaO5/**Lv0PCjtQCgkh8h231IQe4SZjkz2J0V**
zQh1
r3IAnidzPXJfRdV1TEu3b+**qf0jiplsfA
=Lv/W
-END PGP SIGNATURE-

--**--**
-
To unsubscribe, e-mail:
users-unsubscribe@tomcat.**apache.orgusers-unsubscr...@tomcat.apache.org

mailto:users-unsubscribe@**tomcat.apache.orgusers-unsubscr

Re: Dependencies on extensions functionality

2012-02-05 Thread Violeta Georgieva

Hi,

As I wrote I'm placing the extension jar in C:\apache-tomcat-7.0.25\ext.
I tried the following: I specified C:\apache-tomcat-7.0.25\lib as value
for catalina.ext.dirs property and now the web application is working.

But then I have two questions:

- Do we need catalina.ext.dirs at all if we can use only Tomcat's
classpath dirs? Let's look through them instead of introducing additional
property.
- Does this mean that we can use only Tomcat's classpath dirs and we cannot
specify a custom directory for these extensions?

Thanks
Violeta

2012/2/5 Pid p...@pidster.com

 On 04/02/2012 21:02, Violeta Georgieva wrote:
  Hi,
 
  Here is how one can reproduce the scenario:
 
  1. Start Tomcat
  2. Put attached war in webapps folder
  3. In the console the following error message is printed:

 In the example above, where have you placed the extension?  Is it in one
 of Tomcat's classpath directories?


 p

  INFO: Deploying web application archive
  C:\apache-tomcat-7.0.25\webapps\test-web-app.war
  Feb 4, 2012 10:41:44 PM org.apache.catalina.util.ExtensionValidator
  validateManifestResources
  INFO: ExtensionValidator[/test-web-app][Web Application Manifest]:
  Required extension [test-jar] not found.
  Feb 4, 2012 10:41:44 PM org.apache.catalina.util.ExtensionValidator
  validateManifestResources
  INFO: ExtensionValidator[/test-web-app]: Failure to find [1] required
  extension(s).
  Feb 4, 2012 10:41:44 PM org.apache.catalina.core.StandardContext
  startInternal
  SEVERE: Error getConfigured
  Feb 4, 2012 10:41:44 PM org.apache.catalina.core.StandardContext
  startInternal
  SEVERE: Context [/test-web-app] startup failed due to previous errors
 
  4. Stop Tomcat
  5. Create folder - C:\apache-tomcat-7.0.25\ext
  6. Put the attached jar file in the folder created on step 5
  7. Start Tomcat with additional VM argument
  -Dcatalina.ext.dirs=C:/apache-tomcat-7.0.25/ext
  8. This time the application is deployed successfully.
  9. Request http://localhost:8080/test-web-app/TestServlet
  10. Internal Server Error is returned with the following Exception:
 
 
  java.lang.ClassNotFoundException: test.TestExtension
 
 org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1701)
 
 org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1546)
test.TestServlet.doGet(TestServlet.java:28)
javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
 
  I did not change any other Tomcat configuration so it is running with
  defaults.
 
  The scenario is that TestServlet (in war file) instantiates
  TestExtension (in jar file, placed in the ext directory).
 
  Regards
  Violeta
  2012/2/4 Christopher Schultz ch...@christopherschultz.net
  mailto:ch...@christopherschultz.net
 
  Violetta,
 
  On 2/3/12 8:25 AM, Violeta Georgieva wrote:
  I have a web application that specifies in the Manifest that wants
  to use an extension.
 
  I specify catalina.ext.dirs to point to the directory where I
  placed my extensions jar files.
 
  What is the value of the catalina.ext.dirs system property? Where did
  you set it? Can you verify that it is set when the JVM actually starts?
 
  What files are in the directory or directories specified by
  catalina.ext.dir?
 
  Unfortunately when I request my application I'm receiving
  ClassNotFoundException.
 
  What class cannot be found? Is it found in any of the JAR files you
  have in your catalina.ext.dir (which is, of course, the whole point of
  the feature)?
 
  I verified that
 
  ExtensionValidator.validateApplication() succeeded to find the
  extension jar file.
 
  How did you verify this? Are there logs that suggest your JAR file is
  being scanned? Please provide them.
 
  What could be the problem? May be I'm missing some configuration?
 
  You might be, but you haven't provided any configuration to us, so we
  don't know if you're missing something. Clearly, something is
  misconfigured.
 
  -chris
 
  -
  To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
  mailto:users-unsubscr...@tomcat.apache.org
  For additional commands, e-mail: users-h...@tomcat.apache.org
  mailto:users-h...@tomcat.apache.org
  
 
 
 
 
  -
  To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
  For additional commands, e-mail: users-h...@tomcat.apache.org

 --

 [key:62590808]

Re: Dependencies on extensions functionality

2012-02-05 Thread Violeta Georgieva

Hi,

Here is the bug that I created:
https://issues.apache.org/bugzilla/show_bug.cgi?id=52607

I didn't find catalina.ext.dirs property in the documentation.
I just attached the debugger and checked the sources while executing the
scenario ;-)

Thanks and Regards
Violeta

2012/2/5 Konstantin Kolinko knst.koli...@gmail.com

 2012/2/5 Violeta Georgieva miles...@gmail.com:
  Hi,
 
  As I wrote I'm placing the extension jar in
 C:\apache-tomcat-7.0.25\ext.
  I tried the following: I specified C:\apache-tomcat-7.0.25\lib as value
  for catalina.ext.dirs property and now the web application is working.
 
  But then I have two questions:
 
  - Do we need catalina.ext.dirs at all if we can use only Tomcat's
  classpath dirs? Let's look through them instead of introducing additional
  property.

 Good question. Please file a bug in Bugzilla.  You can include a link
 to this thread.

 Searching the sources for catalina.ext.dirs it is mentioned in
 ExtensionValidator.java source only. It is never mentioned in User
 Guide or Configuration Reference.

 It should be added to docs/config/systemprops.html and maybe mentioned
 in docs/class-loader-howto.html


 Searching just for ext.dirs you see one more place,
 AntCompiler.java, that uses just java.ext.dirs and not catalina one.
 So maybe you had to redefine the java.ext.dirs property, like
 catalina.sh does with java.endorsed.dirs.


 I wonder how did you found this catalina.ext.dirs property. From Javadoc?

  - Does this mean that we can use only Tomcat's classpath dirs and we
 cannot
  specify a custom directory for these extensions?

 You can. You can reconfigure classpath in the conf/catalina.properties
 file.

 Best regards,
 Konstantin Kolinko

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Dependencies on extensions functionality

2012-02-06 Thread Violeta Georgieva

I was going to ask you why you were using it!  So is your interest
purely academic?
I have existing applications that are moving to Tomcat from another
application server.
As dependencies on extensions is a standard mechanism for shared
libraries, they use it in order to be independent from the application
servers.

2012/2/6 Pid p...@pidster.com

 On 05/02/2012 15:03, Violeta Georgieva wrote:
  Hi,
 
  As I wrote I'm placing the extension jar in
 C:\apache-tomcat-7.0.25\ext.
  I tried the following: I specified C:\apache-tomcat-7.0.25\lib as value
  for catalina.ext.dirs property and now the web application is working.
 
  But then I have two questions:
 
  - Do we need catalina.ext.dirs at all if we can use only Tomcat's
  classpath dirs? Let's look through them instead of introducing additional
  property.

 I was going to ask you why you were using it!  So is your interest
 purely academic?


  - Does this mean that we can use only Tomcat's classpath dirs and we
 cannot
  specify a custom directory for these extensions?

 It should work.  (As per Konstantin's message)


 p


  Thanks
  Violeta
 
  2012/2/5 Pid p...@pidster.com
 
  On 04/02/2012 21:02, Violeta Georgieva wrote:
  Hi,
 
  Here is how one can reproduce the scenario:
 
  1. Start Tomcat
  2. Put attached war in webapps folder
  3. In the console the following error message is printed:
 
  In the example above, where have you placed the extension?  Is it in one
  of Tomcat's classpath directories?
 
 
  p
 
  INFO: Deploying web application archive
  C:\apache-tomcat-7.0.25\webapps\test-web-app.war
  Feb 4, 2012 10:41:44 PM org.apache.catalina.util.ExtensionValidator
  validateManifestResources
  INFO: ExtensionValidator[/test-web-app][Web Application Manifest]:
  Required extension [test-jar] not found.
  Feb 4, 2012 10:41:44 PM org.apache.catalina.util.ExtensionValidator
  validateManifestResources
  INFO: ExtensionValidator[/test-web-app]: Failure to find [1] required
  extension(s).
  Feb 4, 2012 10:41:44 PM org.apache.catalina.core.StandardContext
  startInternal
  SEVERE: Error getConfigured
  Feb 4, 2012 10:41:44 PM org.apache.catalina.core.StandardContext
  startInternal
  SEVERE: Context [/test-web-app] startup failed due to previous errors
 
  4. Stop Tomcat
  5. Create folder - C:\apache-tomcat-7.0.25\ext
  6. Put the attached jar file in the folder created on step 5
  7. Start Tomcat with additional VM argument
  -Dcatalina.ext.dirs=C:/apache-tomcat-7.0.25/ext
  8. This time the application is deployed successfully.
  9. Request http://localhost:8080/test-web-app/TestServlet
  10. Internal Server Error is returned with the following Exception:
 
 
  java.lang.ClassNotFoundException: test.TestExtension
 
 
 org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1701)
 
 
 org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1546)
test.TestServlet.doGet(TestServlet.java:28)
javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
 
  I did not change any other Tomcat configuration so it is running with
  defaults.
 
  The scenario is that TestServlet (in war file) instantiates
  TestExtension (in jar file, placed in the ext directory).
 
  Regards
  Violeta
  2012/2/4 Christopher Schultz ch...@christopherschultz.net
  mailto:ch...@christopherschultz.net
 
  Violetta,
 
  On 2/3/12 8:25 AM, Violeta Georgieva wrote:
  I have a web application that specifies in the Manifest that wants
  to use an extension.
 
  I specify catalina.ext.dirs to point to the directory where I
  placed my extensions jar files.
 
  What is the value of the catalina.ext.dirs system property? Where did
  you set it? Can you verify that it is set when the JVM actually starts?
 
  What files are in the directory or directories specified by
  catalina.ext.dir?
 
  Unfortunately when I request my application I'm receiving
  ClassNotFoundException.
 
  What class cannot be found? Is it found in any of the JAR files you
  have in your catalina.ext.dir (which is, of course, the whole point of
  the feature)?
 
  I verified that
 
  ExtensionValidator.validateApplication() succeeded to find the
  extension jar file.
 
  How did you verify this? Are there logs that suggest your JAR file is
  being scanned? Please provide them.
 
  What could be the problem? May be I'm missing some configuration?
 
  You might be, but you haven't provided any configuration to us, so we
  don't know if you're missing something. Clearly, something is
  misconfigured.
 
  -chris
 
 
 -
  To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
  mailto:users-unsubscr...@tomcat.apache.org
  For additional commands, e-mail: users-h...@tomcat.apache.org
  mailto:users-h...@tomcat.apache.org

Re: Dependencies on extensions functionality

2012-02-06 Thread Violeta Georgieva

Actually as I wrote in the mail with the scenario:

, when I do not specify the catalina.ext.dirs, deployment fails

INFO: Deploying web application archive
C:\apache-tomcat-7.0.25\webapps\test-web-app.war
Feb 4, 2012 10:41:44 PM org.apache.catalina.util.ExtensionValidator
validateManifestResources
INFO: ExtensionValidator[/test-web-app][Web Application Manifest]:
Required extension [test-jar] not found.
Feb 4, 2012 10:41:44 PM org.apache.catalina.util.ExtensionValidator
validateManifestResources
INFO: ExtensionValidator[/test-web-app]: Failure to find [1] required
extension(s).
Feb 4, 2012 10:41:44 PM org.apache.catalina.core.StandardContext
startInternal

SEVERE: Error getConfigured
Feb 4, 2012 10:41:44 PM org.apache.catalina.core.StandardContext
startInternal
SEVERE: Context [/test-web-app] startup failed due to previous errors

then when I specify catalina.ext.dirs then it fails with CNFE

2012/2/6 Christopher Schultz ch...@christopherschultz.net

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Pid,

 On 2/6/12 6:48 AM, Pid wrote:
  On 06/02/2012 11:08, Violeta Georgieva wrote:
  I was going to ask you why you were using it!  So is your
  interest purely academic?
  I have existing applications that are moving to Tomcat from
  another application server. As dependencies on extensions is a
  standard mechanism for shared libraries, they use it in order to
  be independent from the application servers.
 
  I see - in my experience this mechanism is rarely used in web
  applications.  Interesting.

 Yeah, I had never heard of it.

 Also, the whole metadata-scanning thing seems totally unnecessary: the
 webapp tries to load a class, and the ClassLoader figures it out. The
 fact that the metadata exists doesn't really help much.

 I haven't looked at the validation code, though, so it's possible that
 the container is supposed to refuse to deploy the webapp if an
 appropriate extension isn't available.

 That obviously wasn't happening in Violeta's case because the
 deployment succeeded but then she got a CNFE.

 - -chris
 -BEGIN PGP SIGNATURE-
 Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
 Comment: GPGTools - http://gpgtools.org
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

 iEYEARECAAYFAk8wGqYACgkQ9CaO5/Lv0PAxhQCfQ2NBq+vrLxIREvKp8mFROnw5
 mOUAn194PtKwYxvxKv1BJrTAkmnCksfu
 =X6VY
 -END PGP SIGNATURE-

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Dependencies on extensions functionality

2012-02-06 Thread Violeta Georgieva

Gotcha: so, the validation works properly, but the catalina.ext.dirs
doesn't actually get added to the classpath. Oops.
that's correct

2012/2/6 Christopher Schultz ch...@christopherschultz.net

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Violeta,

 On 2/6/12 1:31 PM, Violeta Georgieva wrote:
  Actually as I wrote in the mail with the scenario:
 
  when I do not specify the catalina.ext.dirs, deployment fails
 
  INFO: Deploying web application archive
  C:\apache-tomcat-7.0.25\webapps\test-web-app.war
  Feb 4, 2012 10:41:44 PM
  org.apache.catalina.util.ExtensionValidator
  validateManifestResources
  INFO: ExtensionValidator[/test-web-app][Web Application
  Manifest]:
  Required extension [test-jar] not found.
  Feb 4, 2012 10:41:44 PM
  org.apache.catalina.util.ExtensionValidator
  validateManifestResources
  INFO: ExtensionValidator[/test-web-app]: Failure to find [1]
  required
  extension(s).
  Feb 4, 2012 10:41:44 PM org.apache.catalina.core.StandardContext
  startInternal
 
  SEVERE: Error getConfigured Feb 4, 2012 10:41:44 PM
  org.apache.catalina.core.StandardContext
  startInternal
  SEVERE: Context [/test-web-app] startup failed due to previous
  errors
 
  then when I specify catalina.ext.dirs then it fails with CNFE

 Gotcha: so, the validation works properly, but the catalina.ext.dirs
 doesn't actually get added to the classpath. Oops.

 - -chris
 -BEGIN PGP SIGNATURE-
 Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
 Comment: GPGTools - http://gpgtools.org
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

 iEYEARECAAYFAk8wHqkACgkQ9CaO5/Lv0PBXdQCgkvcmuAnGBEmcbrUUtPySGqmS
 dJUAoJ1KGf/flTDzmNd0JigGEO+7muMD
 =dog/
  -END PGP SIGNATURE-

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Using local EJBs in web application

2012-02-16 Thread Violeta Georgieva

It's probably just my issue but I am not seeing your war file as valid.

What do you mean?

Re: Using local EJBs in web application

2012-02-16 Thread Violeta Georgieva

Hi,

Which one?

Tomcat + OpenEJB in OSGi environment

Looks like your integration isn't exactly complete.

Yep it cannot reach the OpenEjb at all because there is no binding in the
naming for local EJBs

Local EJB refs aren't bound, only (non-local) EJB refs?

Yep

Looks like nobody has done anything about that.

Tomcat is a servlet container that provides minimal support for EJBs
and things like that. It's no shock to me that something like this is
unimplemented. If you are interested in providing a patch, we'd be
glad to consider it for inclusion.

Thanks. I'll definitely do it today or tomorrow.

Regards
Violeta

2012/2/15 Christopher Schultz ch...@christopherschultz.net

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Violetta,

 On 2/15/12 3:11 PM, Violeta Georgieva wrote:
  I integrated Tomcat 7.0.25 with an EJB container.

 Which one?

  I have simple web application that uses ejb-local-ref (see the
  attachment).
 
  Unfortunately when I request the web application it cannot find the
  ejb at all:
 
  javax.naming.NameNotFoundException: Name ejb is not bound in this
  Context
  org.apache.naming.NamingContext.lookup(NamingContext.java:820)
  org.apache.naming.NamingContext.lookup(NamingContext.java:154)
  org.apache.naming.NamingContext.lookup(NamingContext.java:831)

 Looks like your integration isn't exactly complete.

  I can see that local EJB refs are not bound, but only EJB refs -

 Local EJB refs aren't bound, only (non-local) EJB refs?

  org.apache.catalina.core.NamingContextListener.createNamingContext()
 
   Also in the same class I can see that addLocalEJB method is marked
  as NO-OP.
 
  Is that intentional? What I have to do in order to have this sample
  running?

 Looks like nobody has done anything about that.

 Tomcat is a servlet container that provides minimal support for EJBs
 and things like that. It's no shock to me that something like this is
 unimplemented. If you are interested in providing a patch, we'd be
 glad to consider it for inclusion.

 - -chris
 -BEGIN PGP SIGNATURE-
 Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
 Comment: GPGTools - http://gpgtools.org
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

 iEYEARECAAYFAk88F78ACgkQ9CaO5/Lv0PAmngCgjNb2EMZvQb5owI5td+lRxngk
 xX0AnjGr9t++WXtUn4rURQt4bCWvGVD3
 =xkuk
 -END PGP SIGNATURE-

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Serving static files directly from filesystem

2012-02-21 Thread Violeta Georgieva

Hi Jean,

It appears that we (Eclipse Virgo) have a bug in the documentation :(
Please report it in our bugzilla [1]

We do support Context element with several limitations - see user
documentation [2]

If you want let's continue the discussion in Virgo forum [3]?


[1] https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Virgo
[2]
http://www.eclipse.org/virgo/documentation/virgo-documentation-3.0.2.RELEASE/docs/virgo-user-guide/html/ch11s07.html
-
Context Configuration chapter
[3] http://www.eclipse.org/forums/index.php?t=threadfrm_id=159

Best Regards
Violeta Georgieva

2012/2/21 Jean-Pierre Bergamin jpberga...@gmail.com

 Hello everyone

 2012/2/21 Jean-Pierre Bergamin jpberga...@gmail.com
 
  I'm trying to configure tomcat 7 on Windows to serve static files. During
  development I want to have uncompresses javascript files delivered
 directly
  from the file system.
  I followed this blog post
 
 http://th1rty7.blogspot.com/2009/05/tomcat-is-often-considered-to-be-too.htmland
  configured a context in the server.xml file like:
 

 I just found out why it does not work in my case. Tomcat is running inside
 the Virgo OSGi container where the documentation [1] states:
 The following Tomcat features are not supported: Context elements.

 So this explains why it is not working as expected.

 But thanks for the help anyway.


 Best regards,
 James

 [1]

 http://www.eclipse.org/virgo/documentation/virgo-documentation-3.0.0.x/docs/virgo-programmer-guide/html/ch09s05.html

Re: Using ServletContainerInitializer for 2.5 applications

2012-04-12 Thread Violeta Georgieva

Hi,

This mechanism is meant to be a standard way for web frameworks to extend
the Servlet Container. IMHO this is compliant with the specification:



8.2.4 Shared libraries / runtimes pluggability

In addition to supporting fragments and use of annotations one of the
requirements

is that not only we be able to plug-in things that are bundled in the
WEB-INF/lib

but also plugin shared copies of frameworks - including being able to
plug-in to the

web container things like JAX-WS, JAX-RS and JSF that build on top of the
web

container. The ServletContainerInitializer allows handling such a use case

as described below.


Lazar just wants to extend the Servlet Container using this standard
mechanism. He wants his implementation of ServletContainerInitializer to be
invoked for every web application.

Regards
Violeta

2012/4/12 Pid * p...@pidster.com

 On 11 Apr 2012, at 14:42, Lazar Kirchev lazar.kirc...@gmail.com wrote:

  ServletContainerInitializer

 Only exists in Servlet 3.0. Supporting it in lower spec versions would
 be non-compliant.

 And silly.


 p

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Using ServletContainerInitializer for 2.5 applications

2012-04-17 Thread Violeta Georgieva

Ok I understood.
Thanks

2012/4/12 Christopher Schultz ch...@christopherschultz.net

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Mark,

 On 4/12/12 8:58 AM, ma...@apache.org wrote:
  If you want to use Servlet 3.0 features then you need to declare
  3.0 in the web.xml.

 +1

 Since the spec is (almost entirely) backward-compatible, this shouldn't
 represent an undue hardship. If you have to support customers who
 don't necessarily have a 3.0-spec container available, then you'll
 have to find another way to satisfy your requirement.

 - -chris
 -BEGIN PGP SIGNATURE-
 Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
 Comment: GPGTools - http://gpgtools.org
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

 iEYEARECAAYFAk+HH/AACgkQ9CaO5/Lv0PDLRACfVApXPTtjeyTIBsNVrarNfXto
 mlsAnjThrgVIKKV1ZnoN82RA5/nCG+Jc
 =13Wk
 -END PGP SIGNATURE-

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

Mapping a servlet to the application's context root results in IAE

2012-06-04 Thread Violeta Georgieva

Hi,

I'm using Tomcat 7.0.27.

I have an application and I want to map my servlet to the application's
context root, but I do not want to override the / mapping for the
default servlet.

It is specified in the Servlet spec that there is a special url mapping
that can be used for such purposes and it is an empty string ().

I tried several approaches to specify this via web.xml and annotation:

1) Approach one

  servlet-mapping
   servlet-nameTestServlet/servlet-name
   url-pattern/url-pattern
  /servlet-mapping
2) Approach two

  servlet-mapping
   servlet-nameTestServlet2/servlet-name
   url-pattern/url-pattern
  /servlet-mapping
3) Approach three

@WebServlet(urlPatterns={})

In all three cases I'm receiving:

Caused by: java.lang.IllegalArgumentException: Invalid url-pattern  in
servlet mapping
 at
org.apache.catalina.core.StandardContext.addServletMapping(StandardContext.java:3208)
 at
org.apache.catalina.core.StandardContext.addServletMapping(StandardContext.java:3183)
 at org.apache.catalina.deploy.WebXml.configureContext(WebXml.java:1302)
 at
org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1305)
 at
org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:855)
 at
org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:346)


What I should do in order to have this running?

Thanks in advance
Regards
Violeta


pp: Extract from the spec

12.2 Specification of Mappings
In the Web application deployment descriptor, the following syntax is used
to define
mappings:
■ A string beginning with a ‘/’ character and ending with a ‘/*’ suffix is
used for
path mapping.
■ A string beginning with a ‘*.’ prefix is used as an extension mapping.
■ The empty string () is a special URL pattern that exactly maps to the
application's context root, i.e., requests of the form
http://host:port/contextroot/.
In this case the path info is ’/’ and the servlet path and context path is
empty string (““).
■ A string containing only the ’/’ character indicates the default
servlet of the
application. In this case the servlet path is the request URI minus the
context path
and the path info is null.
■ All other strings are used for exact matches only.

Re: Mapping a servlet to the application's context root results in IAE

2012-06-04 Thread Violeta Georgieva

Here it is: https://issues.apache.org/bugzilla/show_bug.cgi?id=53356

Thanks
Violeta

2012/6/4 Mark Thomas ma...@apache.org

 On 04/06/2012 19:25, Violeta Georgieva wrote:
  Hi,
 
  I'm using Tomcat 7.0.27.
 
  I have an application and I want to map my servlet to the application's
  context root, but I do not want to override the / mapping for the
  default servlet.
 
  It is specified in the Servlet spec that there is a special url mapping
  that can be used for such purposes and it is an empty string ().

 That feature is not implemented in Tomcat. I don't see it in the spec's
 change log which is why I suspect it is so little used that no-one else
 has noticed it doesn't work until now.

 Please file a BZ issue and this should get fixed for the next release.

 Mark

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Offline generation of effective web.xml

2012-09-11 Thread Violeta Georgieva

It would be very useful if I can provide this as part of the build
infrastructure for example.
If you can give me a hint from where to start I may try to provide a patch
for 8.0.x? Wdyt?


2012/9/11 Mark Thomas ma...@apache.org

  Violeta Georgieva violet...@apache.org wrote:

 Hi,
 
 I do know that if I provide logEffectiveWebXml=true in my context.xml
 then the effective web.xml will be logged in the log files during
 application start.
 
 Is there a way (library etc.) that I can use to generated effective
 web.xml
 offline i.e. without starting the application.
 
 Thanks in advance.
 Violeta

 No, although I am beginning to think about refactoring the web.xml
 scanning for 8.0.x for other reasons but any such refactoring should make
 this trivial.

 I haven't got much further than it would be useful if... so it may turn
 out to be impractical.

 Mark

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Offline generation of effective web.xml

2012-09-12 Thread Violeta Georgieva

Thanks for the starting point.
I'm starting to look at the code and when I have the first results I'll
write to the dev list.
Is that OK?

2012/9/11 Konstantin Kolinko knst.koli...@gmail.com

 2012/9/11 Violeta Georgieva miles...@gmail.com:
  It would be very useful if I can provide this as part of the build
  infrastructure for example.
  If you can give me a hint from where to start I may try to provide a
 patch
  for 8.0.x? Wdyt?
 
 
  2012/9/11 Mark Thomas ma...@apache.org
 
   Violeta Georgieva violet...@apache.org wrote:
 
  Hi,
  
  I do know that if I provide logEffectiveWebXml=true in my context.xml
  then the effective web.xml will be logged in the log files during
  application start.
  
  Is there a way (library etc.) that I can use to generated effective
  web.xml
  offline i.e. without starting the application.
  
  Thanks in advance.
  Violeta
 
  No, although I am beginning to think about refactoring the web.xml
  scanning for 8.0.x for other reasons but any such refactoring should
 make
  this trivial.
 
  I haven't got much further than it would be useful if... so it may
 turn
  out to be impractical.
 

 1. Logging the effective web.xml is performed in
 o.a.c.startup.ContextConfig.
 Search for
 org.apache.tomcat.util.scan.Constants.MERGED_WEB_XML

 2. I would like to remove this MERGED_WEB_XML
 from future versions. Instead of re-parsing web.xml Jasper would
 better be using Servlet API to query needed features.

 IIRC, actually Jasper does not need much: just specification version
 and jsp-config.

 A downside is that Jasper has to be used stand-alone as JspC. So it
 should still be able to parse web.xml. So either
 a) refactor the whole parsing of web.xml, moving it into reusable
 component (like Mark wrote),  or
 b) keep the current parsing code in Jasper and make its own objects
 implement relevant parts of Servlet API.

 This is filed as BZ53737. The first attempt was in r1377511
 (+discussion), reverted in r1377539.

 https://issues.apache.org/bugzilla/show_bug.cgi?id=53737
 http://markmail.org/message/dyuyuuglunuy4qej
 http://markmail.org/message/kknk2xh7wdcznsv7

 3. Note, that currently this merged web xml may miss some features.

 - It may change the order of elements vs. original web.xml. There are
 a number of elements whose order is not important. Tomcat uses HashMap
 for those, so their order may change randomly from run to run.

 - It may miss some elements from original web.xml, that are not parsed
 by Tomcat. Such as descriptions.

 Several weeks ago I went through the code, correcting some typos in
 element names and wrong order of elements.

 Best regards,
 Konstantin Kolinko

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

CsrfPreventionFilter for REST

2012-09-21 Thread Violeta Georgieva

Hello,

** **

*Background information:*

We are trying to protect our RESTful
APIshttp://en.wikipedia.org/wiki/Representational_state_transfer
from
CSRF attack.

The current Tomcat’s CSRF protection filter provides proper protection for
web resources that are supposed to be accessed via some sort of navigation
i.e. there’s an entry point which points to them (for example include
links/post forms to them) . With REST APIs you do not have such entry
points as the requests are done independently from each other.  We are
interested do you consider supporting  CSRF protection for RESTful APIs?

** **

*Example attack:*

Here is an example how to reproduce CSRF attack of RESTful APIs using the
attached apps:


   1. Check customers initial state:
   http://localhost:8080/restDemo/services/customers/  + login with
   tomcat/tomcat
   2.  **In the same browser open attacker’s app:
   http://localhost:8080/XSRFAttackerApp/

**

Behind the scenes request 2. takes advantage of your credentials stored in
the browser and makes attacking POST request to a state changing operation
http://localhost:8080/restDemo/services/customers/removeFirst on your
behalf. After that the customer list is empty.

** **

The problem is that if we use the CSRF filter to protect this API
/services/customers/removeFirst, this URL is then always served with *403
Forbidden* (due to the missing csrf token).  In fact  the REST API becomes
unusable.

** **

*Research:*

We’ve made some research on the topic and it seems that there is no
absolutely secure and at the same time clear stateless solution. Since it
is possible for an attacker to insert  custom headers in the attacking
requests, the validation over header presence is not secure enough.

The only stable solution is again based on Synchronizer Token
Patternhttps://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet
but
instead of encoded in URLs, the csrf token value can be transferred from
and to the client through a custom csrf token header.  The rest csrf  token
value needs to be stored in some sort of state on client and server side.
In addition REST clients need to adopt this csrf token transfer mechanism.**
**

*Proposal:*

You can find on the link
https://docs.google.com/open?id=0B-HUwAvkRIKJTVViWUFkNFl6alU , the
CsrfPreventionFilter extended so that it is able to successfully protect
state changing REST requests. They are validated based on the
“X-CSRF-Token” header (the header name is configurable).

*
*

*Here are some details about the new protection mechanism:*


   1. How to recognize REST from non REST requests so that they can be
   validated separately - based on different tokens? - There is no clear
   way to recognize them, that’s why application developers should point all
   rest API URLs in the application through a new filter init parameter named
   *restApis*.
   2. How the valid client gets to know the valid CSRF Token? - In order a
   REST client (e.g. adapted HTTP client) to obtain a valid CSRF token and use
   it for its REST requests it should make an initial non modifying request
   (GET, HEAD, OPTIONS) to the application. This request should
contain  ‘*X-CRF-Token:
   Fetch’ *header*. *On such request, the filter generates and stores a
   rest csrf token as a session attribute and returns it together with the
   jsessionid to the client.
   3. The Client should send the pair j*sessionid* and * csrf token* header*
*whenever it makes modifying REST requests to this application (POST,
   PUT, DELETE etc.).
   4. How are invalid state changing requests handled? - They are responded
   with HTTP/1.1 403 Forbidden + ‘X-CSRF-Token: Required’ header.



Below you can find example request response process flow. It  is based on
the example app - restDemo (also available on the link with the extended
filter).

To try it yourself: apply the patch, remove the commented CSRF protection
configuration in restDemo’s web.xml and deploy.
*

1.**Client Request 1:**
*GET /restDemo/services/customers/ HTTP/1.1
X-CSRF-Token: Fetch
Authorization: Basic dG9tY2F0OnRvbWNhdA==
Host: localhost:8080
*
*
*Server Response1:*
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Cache-Control: private
Expires: Thu, 01 Jan 1970 03:00:00 EET
*Set-Cookie: JSESSIONID=4BA3D75B73B8C4591F1D915BA9C2B660; Path=/restDemo/;
HttpOnly*
*X-CSRF-Token: 5A44B387B75E54417F6C64FF3D485141*
Content-Type: application/xml
Content-Length: 170
Date: Fri, 21 Sep 2012 17:53:02 GMT
*
*
*2.   Client Request 2:*
POST /restDemo/services/customers/removeFirst HTTP/1.1
*Cookie: JSESSIONID=4BA3D75B73B8C4591F1D915BA9C2B660*
*X-CSRF-Token: 5A44B387B75E54417F6C64FF3D485141*
Authorization: Basic dG9tY2F0OnRvbWNhdA==
Host: localhost:8080
*
*
*Server Response2:*
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
*Set-Cookie: JSESSIONID=03D21FD4498B1446F12A3796441E2598; Path=/restDemo/;
HttpOnly   - sessionid is rechanged after reauthentication (this is not
related to our

Re: CsrfPreventionFilter for REST

2012-09-25 Thread Violeta Georgieva

Hi,

Did you have a chance to check the issue and the proposal?
Can I provide more information in order to make to them clearer?

Thanks a lot.
Violeta

2012/9/21 Violeta Georgieva violet...@apache.org

Hello,

** **

*Background information:*

We are trying to protect our RESTful
APIshttp://en.wikipedia.org/wiki/Representational_state_transfer from
CSRF attack.

The current Tomcat’s CSRF protection filter provides proper protection for
web resources that are supposed to be accessed via some sort of navigation
i.e. there’s an entry point which points to them (for example include
links/post forms to them) . With REST APIs you do not have such entry
points as the requests are done independently from each other. We are
interested do you consider supporting CSRF protection for RESTful APIs?**
**

** **

*Example attack:*

Here is an example how to reproduce CSRF attack of RESTful APIs using the
attached apps:

1. Check customers initial state:
http://localhost:8080/restDemo/services/customers/ + login with
tomcat/tomcat
2. **In the same browser open attacker’s app:
http://localhost:8080/XSRFAttackerApp/

Behind the scenes request 2. takes advantage of your credentials stored in
the browser and makes attacking POST request to a state changing operation
http://localhost:8080/restDemo/services/customers/removeFirst on your
behalf. After that the customer list is empty.

** **

The problem is that if we use the CSRF filter to protect this API
/services/customers/removeFirst, this URL is then always served with *403
Forbidden* (due to the missing csrf token). In fact the REST API
becomes unusable.

** **

*Research:*

We’ve made some research on the topic and it seems that there is no
absolutely secure and at the same time clear stateless solution. Since it
is possible for an attacker to insert custom headers in the attacking
requests, the validation over header presence is not secure enough.

The only stable solution is again based on Synchronizer Token
Patternhttps://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet
but
instead of encoded in URLs, the csrf token value can be transferred from
and to the client through a custom csrf token header. The rest csrf token
value needs to be stored in some sort of state on client and server side.
In addition REST clients need to adopt this csrf token transfer mechanism.

*Proposal:*

You can find on the link
https://docs.google.com/open?id=0B-HUwAvkRIKJTVViWUFkNFl6alU , the
CsrfPreventionFilter extended so that it is able to successfully protect
state changing REST requests. They are validated based on the
“X-CSRF-Token” header (the header name is configurable).

*
*

*Here are some details about the new protection mechanism:*

1. How to recognize REST from non REST requests so that they can be
validated separately - based on different tokens? - There is no clear
way to recognize them, that’s why application developers should point all
rest API URLs in the application through a new filter init parameter named
*restApis*.
2. How the valid client gets to know the valid CSRF Token? - In order
a REST client (e.g. adapted HTTP client) to obtain a valid CSRF token and
use it for its REST requests it should make an initial non modifying
request (GET, HEAD, OPTIONS) to the application. This request should
contain ‘*X-CRF-Token: Fetch’ *header*. *On such request, the filter
generates and stores a rest csrf token as a session attribute and returns
it together with the jsessionid to the client.
3. The Client should send the pair j*sessionid* and * csrf token*
header* *whenever it makes modifying REST requests to this
application (POST, PUT, DELETE etc.).
4. How are invalid state changing requests handled? - They are
responded with HTTP/1.1 403 Forbidden + ‘X-CSRF-Token: Required’ header.

Below you can find example request response process flow. It is based on
the example app - restDemo (also available on the link with the extended
filter).

To try it yourself: apply the patch, remove the commented CSRF protection
configuration in restDemo’s web.xml and deploy.
*

1.**Client Request 1:**
*GET /restDemo/services/customers/ HTTP/1.1
X-CSRF-Token: Fetch
Authorization: Basic dG9tY2F0OnRvbWNhdA==
Host: localhost:8080
*
*
*Server Response1:*
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Cache-Control: private
Expires: Thu, 01 Jan 1970 03:00:00 EET
*Set-Cookie: JSESSIONID=4BA3D75B73B8C4591F1D915BA9C2B660;
Path=/restDemo/; HttpOnly*
*X-CSRF-Token: 5A44B387B75E54417F6C64FF3D485141*
Content-Type: application/xml
Content-Length: 170
Date: Fri, 21 Sep 2012 17:53:02 GMT
*
*
*2. Client Request 2:*
POST /restDemo/services/customers/removeFirst HTTP/1.1
*Cookie: JSESSIONID=4BA3D75B73B8C4591F1D915BA9C2B660*
*X-CSRF-Token

Re: JspC failure in Tomcat 7.0.35???

2013-01-17 Thread Violeta Georgieva

2013/1/17 Jess Holle je...@ptc.com

 As part of testing Tomcat 7.0.35 when I moved to it, I run an Ant script
 to pre-compile all our JSP pages.

 When doing so I get a huge number of new failures which boil down to the
 following stack trace.  Any ideas here?  I can dig in to try to see what's
 causing this, but this is new behavior.

 Poking around in the running web app, things seem to work, so the issue
 seems specific to using Jasper for pre-compilation.

   [jasper2] java.lang.NullPointerException
   [jasper2] at org.apache.jasper.compiler.**TagPluginManager.init(**
 TagPluginManager.java:83)
   [jasper2] at org.apache.jasper.compiler.**TagPluginManager.apply(**
 TagPluginManager.java:57)
   [jasper2] at org.apache.jasper.compiler.**Compiler.generateJava(**
 Compiler.java:240)


Check this https://issues.apache.org/bugzilla/show_bug.cgi?id=54440

Regards
Violeta

Re: Configuring WebappClassloader Delegate=True

2013-01-21 Thread Violeta Georgieva

Hi,

2013/1/21 Peter Lavin


 Dear List,

 can anybody tell me how I can configure the WebappClassLoader to not be
 the default Delegate=false to be Delegate=True ?

 thanks,
 Peter


Check this
http://tomcat.apache.org/tomcat-7.0-doc/config/loader.html#Common_Attributes

Regards
Violeta

Re: Tomcat binaries archive

2013-02-06 Thread Violeta Georgieva

2013/2/7 Vihari Piratla :
 Hai,
 Where can we find tomcat binaries archive.
 I found this one http://archive.apache.org/dist/tomcat/tomcat-7 but it
 contains only src files, where can we find binaries?

The link is correct. I can see the archives.
Open the link. Choose the version and then the binaries are in the bin folder.
e.g. http://archive.apache.org/dist/tomcat/tomcat-7/v7.0.34/bin/

 Thank you.

 --
 Vihari Piratla.

Regards
Violeta

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Catalina.out

2013-03-04 Thread Violeta Georgieva

2013/3/4  vicky007aggar...@yahoo.co.in:
 I am using tomcat 7.0.30(os: redhat linux)  referring below link for 
 implementing log4j at the container level

  http://tomcat.apache.org/tomcat-6.0-doc/logging.html#Using_Log4j

 Using this link i am still not able to rotate the
 Catalina.out , is it feasible to do that,if yes then
 can someone please share
 the steps/guide me on this

http://wiki.apache.org/tomcat/FAQ/Logging#Q10

 Thanks,
 Vicky



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: FW: Tomcat 5.5.20 not stopping and starting correctly

2013-04-10 Thread Violeta Georgieva

Hi,

2013/4/10 Tailor,Nilesh wrote:

 Hi,

 We currently have an issue whereby Tomcat 5.5.20 does not seem to stop
and start correctly.  When we stop the service the below message appears:

 'Windows could not stop the Apache Tomcat 5.5.20 service on Local
Computer. Error 109: The pipe has been ended.'

 When we start the service, we are not able to bring up the page.  I have
looked through logs and nothing is appearing in the tomcat logs which to
suggest what is causing the issue.

 Has anyone experienced this issue before?


It is possible that you are facing a known issue [1].

Please note that Tomcat 5.5.x is not supported anymore [2].

Regards
Violeta

[1] https://issues.apache.org/jira/browse/DAEMON-195
[2] http://tomcat.apache.org/tomcat-55-eol.html

Re: tomcat reload single application command

2013-04-15 Thread Violeta Georgieva

Hi,


2013/4/15 naouguh_tomcat wrote:

 Hi All,

 Can someone tell me how to reload one application of tomcat in the
command line ?



Please check this [1].

Regards
Violeta

[1]
http://tomcat.10.x6.nabble.com/Command-line-reloading-of-a-webapp-td2038007.html

Re: tomcat7 tldScanJar warning

2013-07-15 Thread Violeta Georgieva

2013/7/15 Chris Cheshire wrote:

 On Fri, Jul 12, 2013 at 9:38 AM, Christopher Schultz 
 ch...@christopherschultz.net wrote:

  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA256
 I changed the web.xml declaration to


You need to add metadata-complete=true. See below:

 web-app version=3.0
  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_3_0.xsd;
metadata-complete=true

Regards
Violeta

Re: OSGi in Tomcat

2013-07-23 Thread Violeta Georgieva

2013/7/23 Leonardo Torres wrote:

 Hi guys,

 I would like to know how can I integrate tomcat with osgi (Equinox)?


What exactly do you need?
- OSGi running inside Tomcat
- Or Tomcat running inside OSGi environment. If this is what you need then
you can look at http://eclipse.org/gemini/web


Regards
Violeta


 thank´s.
 --
 Obrigado
 Leonardo Torres.

Re: OSGi in Tomcat

2013-07-23 Thread Violeta Georgieva

2013/7/23 Leonardo Torres wrote:

 Let me explain my scenario, so you can help me.

 I have an application that uses the implementation of tomcat to websocket,
 and this application need to find services dynamically. So I need to use
 OSGi as service repository.

 I believe embed OSGi in tomcat, work in my scenario.



Then check that http://eclipse.dzone.com/articles/embedding-osgi-tomcat

Re: OSGi in Tomcat

2013-07-24 Thread Violeta Georgieva

2013/7/23 Leonardo Torres wrote:

 Thank´s for reply.

 Just one more question, If I want to use tomcat inside of OSGi
environment,
 how can I do that ?


Check Gemini Web documentation:

http://www.eclipse.org/gemini/web/documentation/
http://wiki.eclipse.org/Gemini/Web

Regards
Violeta

Re: OSGi in Tomcat

2013-07-24 Thread Violeta Georgieva

2013/7/25 Leonardo Torres wrote:

 Thank´s. In my case, It´s not a problem the incompatibility. :)

 Sorry for my question, but in this case, I create a class that inherits
 from WebSocketServlet and use HttpService to register it?

You create a class that inherits WebSocketServlet and pack it as in normal
war.
Then install the archive in OSGi and that's all.
There is no need of HttpService.

If you are interested in Gemini Web we can move the discussion here [1]


Regards
Violeta

[1] http://www.eclipse.org/forums/index.php?t=threadfrm_id=153;

Re: EL 3.0 Constructor Reference

2013-08-17 Thread Violeta Georgieva

2013/8/14 Daniel Mikusa wrote:

 In the EL 3.0 Spec, section 1.22.3 Constructor Reference  states A
class name reference, followed by arguments in parenthesis, such as
Boolean(true) denotes the invocation of the constructor of the class with
the supplied arguments.

 This leads me to believe that the following test should work:

 @Test
 public void testImport03() {
 ELProcessor processor = new ELProcessor();
 Object result =
 processor.getValue(Integer('1000'),
 Integer.class);
 Assert.assertEquals(Integer.valueOf(1000), result);
 }

 Unfortunately, this fails with the following error.

 javax.el.ELException: Function ':Integer' not found
 at org.apache.el.parser.AstFunction.getValue(AstFunction.java:136)
 at
org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:188)
 at javax.el.ELProcessor.getValue(ELProcessor.java:45)
 at
org.apache.el.parser.TestAstIdentifier.testImport03(TestAstIdentifier.java:53)
 …

This is a bug.
Can you create an issue in BZ?

Thanks
Violeta

Re: (MY Tomcat version :- 7.0.40 and deployed on CentOS

2013-08-29 Thread Violeta Georgieva

2013/8/29 Sushil Prusty wrote:

 Hi

 I need to configure OCSP in tomcat for my project and need to test through
 client browser .
 I searched every where in all search engine but unable to find out .

 Please help out on How can we configure OCSP in tomcat.


http://tomcat.10.x6.nabble.com/Standard-or-OCSP-Native-Lib-td4995978.html

Regards
Violeta

[ANN] Apache Tomcat 7.0.47 released

2013-10-26 Thread Violeta Georgieva

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 7.0.47.

Apache Tomcat is an open source software implementation of the Java
Servlet, JavaServer Pages and Java Expression Language technologies.

This release contains a number of bug fixes and improvements compared to
version 7.0.42. The notable changes include:
- Back-port the JSR-356 Java WebSocket 1.0 implementation from Apache
  Tomcat 8.
- Deprecate the Apache Tomcat proprietary WebSocket API in favour of the
  new JSR-356 implementation.
- Add a drawing board example to the WebSocket examples.

Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-7.0-doc/changelog.html

Note: This version has 4 zip binaries: a generic one and
  three bundled with Tomcat native binaries for Windows operating
systems
  running on different CPU architectures.

Note: Use of the JSR-356 Java WebSocket 1.0 implementation requires Java 7.

Note: If you use the APR/native AJP or HTTP connector you *must* upgrade
  to version 1.1.29 or later of the APR/native library.

Downloads:
http://tomcat.apache.org/download-70.cgi

Migration guides from Apache Tomcat 5.5.x and 6.0.x:
http://tomcat.apache.org/migration.html

Re: [ANN] Apache Tomcat 7.0.47 released

2013-10-27 Thread Violeta Georgieva

2013/10/27 Johan Compagner jcompag...@servoy.com

 On 26 October 2013 21:59, Violeta Georgieva violet...@apache.org wrote:

  This release contains a number of bug fixes and improvements compared to
  version 7.0.42. The notable changes include:
  - Back-port the JSR-356 Java WebSocket 1.0 implementation from Apache
Tomcat 8.
  - Deprecate the Apache Tomcat proprietary WebSocket API in favour of the
new JSR-356 implementation.
  - Add a drawing board example to the WebSocket examples.
 


 i guess this page should now be updated:

 http://tomcat.apache.org/whichversion.html

Thanks for pointing that.
It should be fixed now.

 --
 Johan Compagner
 Servoy


Regards
Violeta

Re: [ANN] Apache Tomcat 7.0.47 released

2013-10-28 Thread Violeta Georgieva

2013/10/27 Johan Compagner jcompag...@servoy.com

 

i guess this page should now be updated:
  
   http://tomcat.apache.org/whichversion.html
 
  Thanks for pointing that.
  It should be fixed now.
 
 
 
 only that the minimum version of Tomcat 7 is now not always java 6 ;)

fixed

Re: Configuring Embedded Tomcat for SSL

2013-11-01 Thread Violeta Georgieva

2013/11/1 Matthew Westwood-Hill matthew.westwood-h...@nuix.com

 Tomcat version: 7.0.47

 OS: Windows 7 (x64)

 JDK: 1.7



 I am attempting to start an embedded instance of Tomcat, which is
 configured for SSL only, on port 443.  The code I am using is as follows:



*public* *static* *void* *main*(String[] args)
 *throws*UnknownHostException, LifecycleException, ServletException {

   Tomcat tomcat = *new* Tomcat();



   tomcat.setBaseDir(D:\\Temp);

   tomcat.addWebapp(/sslapp, D:\\);



   Connector connector = *new* Connector();

   connector.setPort(443);

   connector.setScheme(https);

   connector.setSecure(*true*);



   connector.setAttribute(address, 127.0.0.1);

   connector.setAttribute(SSLEnabled, *true*);



   connector.setAttribute(bindOnInit, *true*);



   connector.setAttribute(keystoreFile,
 ...\\EngineInstance.keystore);

   connector.setAttribute(keystorePass, password);

   connector.setAttribute(clientAuth, false);

   connector.setAttribute(sslProtocol, TLS);

   connector.setAttribute(keyAlias, test);

   connector.setAttribute(keyPass, password);



   tomcat.setConnector(connector);

   tomcat.init();

  tomcat.start();

   tomcat.getServer().await();



}



 When I run the above, I receive the following output:



 Nov 01, 2013 10:08:07 AM org.apache.catalina.core.StandardService
 startInternal

 INFO: Starting service Tomcat

 Nov 01, 2013 10:08:07 AM org.apache.catalina.core.StandardEngine
 startInternal

 INFO: Starting Servlet Engine: Apache Tomcat/7.0.47

 Nov 01, 2013 10:08:07 AM org.apache.catalina.startup.ContextConfig
 getDefaultWebXmlFragment

 INFO: No global web.xml found



 It does not look like the connector I created is actually being started.
  When I try browsing to the above port using Chrome/IE all it does not
 connect.



 I thought I was following the correct process base don information I
 located on Google, however, it would appear I am still doing something
 incorrect.



 I have confirmed the existence of the private key in the keystore (using
 Keystore Explorer), so all that is fine.

 Please, any help would be greatly appreciated.



You may want to check how Embedded Tomcat is used in Tomcat's tests [1].

Regards
Violeta

[1]
http://svn.apache.org/repos/asf/tomcat/tc7.0.x/trunk/test/org/apache/catalina/startup/TomcatBaseTest.java

Re: Accessing ServletContext from WebSocket endpoint

2013-12-05 Thread Violeta Georgieva

Hi,


2013/12/5 Enrico Olivelli eolive...@gmail.com

 Hi,
 is there a standard way to access ServletContext from a WebSocket
ServerEndpoint ?

Recently there was such discussion:
http://markmail.org/message/pqkzatjastefxvd6?q=Tomcat+8+Websockets+configuration+list:org%2Eapache%2Etomcat%2Euser/

Regards
Violeta

[ANN] Apache Tomcat 7.0.50 released

2014-01-12 Thread Violeta Georgieva

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 7.0.50.

Apache Tomcat is an open source software implementation of the Java
Servlet, JavaServer Pages and Java Expression Language technologies.

This release contains a number of bug fixes and improvements compared to
version 7.0.47.

Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-7.0-doc/changelog.html

Note: This version has 4 zip binaries: a generic one and
  three bundled with Tomcat native binaries for Windows operating
  systems running on different CPU architectures.

Note: Use of the JSR-356 Java WebSocket 1.0 implementation requires Java 7.

Note: If you use the APR/native AJP or HTTP connector you *must* upgrade
  to version 1.1.29 or later of the APR/native library.

Downloads:
http://tomcat.apache.org/download-70.cgi

Migration guides from Apache Tomcat 5.5.x and 6.0.x:
http://tomcat.apache.org/migration.html

Re: [ANN] Apache Tomcat 7.0.50 released

2014-01-16 Thread Violeta Georgieva

2014/1/12 David Law tomcat.u...@apconsult.de

 Thanks for that. :-)

 You might like to correct this Typo under Tomcat 7.0.50 / Catalina:
 Streamline handling of WebSocket messages whe...
 to when or where for example.

Thanks for pointing that. I fixed it with r1558789.

Regards
Violeta

 All the best,
 DaveLaw


 On 12/01/2014 11:15, Violeta Georgieva wrote:

 The Apache Tomcat team announces the immediate availability of Apache
 Tomcat 7.0.50.

 Apache Tomcat is an open source software implementation of the Java
 Servlet, JavaServer Pages and Java Expression Language technologies.

 This release contains a number of bug fixes and improvements compared to
 version 7.0.47.

 Please refer to the change log for the complete list of changes:
 http://tomcat.apache.org/tomcat-7.0-doc/changelog.html

 Note: This version has 4 zip binaries: a generic one and
three bundled with Tomcat native binaries for Windows
operating
systems running on different CPU architectures.

 Note: Use of the JSR-356 Java WebSocket 1.0 implementation requires Java
7.

 Note: If you use the APR/native AJP or HTTP connector you *must* upgrade
to version 1.1.29 or later of the APR/native library.

 Downloads:
 http://tomcat.apache.org/download-70.cgi

 Migration guides from Apache Tomcat 5.5.x and 6.0.x:
 http://tomcat.apache.org/migration.html



 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat embedded deprecated

2014-02-10 Thread Violeta Georgieva

Hi,


2014-02-10 Tommy Pham tommy...@gmail.com:

 Hi folks,

 I'm seeing:

 @Deprecated 
http://docs.oracle.com/javase/7/docs/api/java/lang/Deprecated.html?is-external=true

 public class Embedded

 at doc site [1] which I presume that the embedded is removed in 8.x?
 Could
 someone please explain why it's deprecated or point me in the right
 direction of why it's deprecated?

It is there:

Deprecated.
Use Tomcat instead.
[1]

Checke this presentation [2]. It's a good starting point.


Regards
Violeta

[1]
http://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/catalina/startup/Tomcat.html
[2]
http://people.apache.org/~markt/presentations/2010-11-04-Embedding-Tomcat.pdf

[ANN] Apache Tomcat 7.0.52 released

2014-02-19 Thread Violeta Georgieva

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 7.0.52.

Apache Tomcat is an open source software implementation of the Java
Servlet, JavaServer Pages and Java Expression Language technologies.

This release contains a number of bug fixes and improvements compared to
version 7.0.50.

Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-7.0-doc/changelog.html

Note: This version has 4 zip binaries: a generic one and
  three bundled with Tomcat native binaries for Windows operating
  systems running on different CPU architectures.

Note: Use of the JSR-356 Java WebSocket 1.0 implementation requires Java 7.

Note: If you use the APR/native AJP or HTTP connector you *must* upgrade
  to version 1.1.29 or later of the APR/native library.

Downloads:
http://tomcat.apache.org/download-70.cgi

Migration guides from Apache Tomcat 5.5.x and 6.0.x:
http://tomcat.apache.org/migration.html

Re: [ANN] Apache Tomcat 7.0.52 released

2014-02-20 Thread Violeta Georgieva

Hi,

2014-02-20 10:44 GMT+02:00 Maarten van Hulsentop maar...@vanhulsentop.nl:

 Hello Violeta,

 On the security vulnerability site
https://tomcat.apache.org/security-7.html,
 issue CVE-2014-0050
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0050is
 still reported to be fixed in 7.0.51, which is stated as not yet
 released.
 I assume the fix is delivered in 7.0.52 as well, but the vulnerability
page
 is not updated yet. Can you confirm this?

I updated the security page.
Thanks for pointing this.

Regards
Violeta

 Thank you very much!

 Regards,

 Maarten




 2014-02-19 13:10 GMT+01:00 Violeta Georgieva miles...@gmail.com:

  The Apache Tomcat team announces the immediate availability of Apache
  Tomcat 7.0.52.
 
  Apache Tomcat is an open source software implementation of the Java
  Servlet, JavaServer Pages and Java Expression Language technologies.
 
  This release contains a number of bug fixes and improvements compared to
  version 7.0.50.
 
  Please refer to the change log for the complete list of changes:
  http://tomcat.apache.org/tomcat-7.0-doc/changelog.html
 
  Note: This version has 4 zip binaries: a generic one and
three bundled with Tomcat native binaries for Windows
operating
systems running on different CPU architectures.
 
  Note: Use of the JSR-356 Java WebSocket 1.0 implementation requires
Java 7.
 
  Note: If you use the APR/native AJP or HTTP connector you *must* upgrade
to version 1.1.29 or later of the APR/native library.
 
  Downloads:
  http://tomcat.apache.org/download-70.cgi
 
  Migration guides from Apache Tomcat 5.5.x and 6.0.x:
  http://tomcat.apache.org/migration.html

Tomcat 7 Session Persistence disable not working as expected

2014-03-09 Thread Violeta Georgieva

Hi,

На понеделник, 10 март 2014 г. Akash Jain akash.delh...@gmail.com написа:
 As documented in

https://tomcat.apache.org/tomcat-5.5-doc/config/manager.html#Disable_Session_Persistence
,
 I added the following code piece to disable session persistence in
 Tomcat
 7.

What is the exact version of Tomcat?

The correct documentation for Tomcat 7 is [1].

Regards,
Violeta

[1]
http://tomcat.apache.org/tomcat-7.0-doc/config/manager.html#Disable_Session_Persistence

 Manager pathname= /

 After this change I can see that SESSIONS.ser is not getting created as
 expected, but even after restarting tomcat, the previous JSESSIONID is
 still valid. Why is tomcat not invalidating the previous JSESSIONID ?

[ANN] Apache Tomcat 7.0.53 released

2014-04-01 Thread Violeta Georgieva

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 7.0.53.

Apache Tomcat is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Expression Language and Java
WebSocket technologies.

This release contains a number of bug fixes and improvements compared to
version 7.0.52. The notable changes since 7.0.52 include:

- Update the Eclipse JDT compiler to enable full Java 8 support in JSPs.

Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-7.0-doc/changelog.html

Note: This version has 4 zip binaries: a generic one and
  three bundled with Tomcat native binaries for Windows operating
  systems running on different CPU architectures.

Note: Use of the JSR-356 Java WebSocket 1.0 implementation requires Java 7.

Note: If you use the APR/native AJP or HTTP connector you *must* upgrade
  to version 1.1.29 or later of the APR/native library.

Downloads:
http://tomcat.apache.org/download-70.cgi

Migration guides from Apache Tomcat 5.5.x and 6.0.x:
http://tomcat.apache.org/migration.html

- The Apache Tomcat team

[ANN] Apache Tomcat 7.0.54 released

2014-05-25 Thread Violeta Georgieva

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 7.0.54.

Apache Tomcat is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Expression Language and Java
WebSocket technologies.

This release contains a number of bug fixes and improvements compared to
version 7.0.53. The notable changes since 7.0.53 include:

- Extend and improve memory leak protection and fix a few leaks that crept
   in during the various refactorings.
- Add additional protection against a failure to correctly recycle the
request
   and response objects.
- APR/native library version updated to 1.1.30.


Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-7.0-doc/changelog.html

Note: This version has 4 zip binaries: a generic one and
  three bundled with Tomcat native binaries for Windows operating
  systems running on different CPU architectures.

Note: Use of the JSR-356 Java WebSocket 1.0 implementation requires Java 7.

Note: If you use the APR/native AJP or HTTP connector you *must* upgrade
  to version 1.1.30 or later of the APR/native library.

Downloads:
http://tomcat.apache.org/download-70.cgi

Migration guides from Apache Tomcat 5.5.x and 6.0.x:
http://tomcat.apache.org/migration.html

- The Apache Tomcat team

Re: Release schedule for 7.0.55?

2014-07-01 Thread Violeta Georgieva

Hi,


2014-07-01 16:26 GMT+03:00 Woonsan Ko woon_...@yahoo.com.invalid:

 Hi,

 Is there any schedule to release 7.0.55?

Follow http://marc.info/?t=14032945371r=1w=2

Regards
Violeta

 I hope to have a fix for 56529 in my project deployment.

 Thanks in advance,

 Woonsan

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

Re: 7.0.54 Startup Times - Going from 700 seconds to 39 seconds

2014-07-18 Thread Violeta Georgieva

Hi,


2014-07-18 2:05 GMT+03:00 George Sexton geor...@mhsoftware.com:

 So I was working on getting tomcat 7.0.54 to run my app. I setup  a
configuration with 725 virtual hosts. Startup time was around 700+ seconds.
For this app, there's maybe two dozen jars in $CATALINA_BASE/lib, and one
1.2MB jar in context/WEB-INF/lib. It is running under the security manager.

 Setting startStopThreads=4 at the Engine level cut that down to around
300 seconds. startStopThreads higher than 4 actually performed worse.

 Adding meta-complete to web.xml took it down to around 260 seconds.

 Adding absolute-ordering / to web.xml with startStopThreads=0 took it
down to 39 seconds. I admit, I'm kind of curious as to what it is that has
to be done by this absolute-ordering thing that is so resource intensive it
has such a massive impact on start times. I've read through the docs on
optimizing startup, and I'm still not seeing it.

 I suppose I'm trying to understand how the impact of this so dramatically
outweighs my app's startup, which includes loading the jar, initializing a
lot of classes, connecting to the database, starting background threads,
etc. It just seems really odd.

 Can anyone help me understand this?

Read this http://wiki.apache.org/tomcat/HowTo/FasterStartUp

Regards,
Violeta


 --
 George Sexton
 *MH Software, Inc.*
 Voice: 303 438 9585
 http://www.mhsoftware.com

Re: 7.0.54 Startup Times - Going from 700 seconds to 39 seconds

2014-07-19 Thread Violeta Georgieva

2014-07-19 20:26 GMT+03:00 George Sexton geor...@mhsoftware.com:


 On 7/18/2014 11:02 PM, Violeta Georgieva wrote:

 Hi,

 I suppose I'm trying to understand how the impact of this so dramatically
 outweighs my app's startup, which includes loading the jar, initializing
a
 lot of classes, connecting to the database, starting background threads,
 etc. It just seems really odd.

 Can anyone help me understand this?

 Read this http://wiki.apache.org/tomcat/HowTo/FasterStartUp



 I read that, and it told me how to make it go faster, which I did. What
I'm trying to understand is what it is that makes that single thing add so
much overhead. As I mentioned in my original post, it just seems
counter-intuitive that the work required would exceed loading my app,
initializing the classes, connecting to the database, starting threads, etc.


The absolute-ordering element specifies which web fragment JARs
(according to the names in their WEB-INF/web-fragment.xml files) have to be
scanned for SCIs, fragments and annotations. An empty absolute-ordering/
element configures that none are to be scanned.

If you have jar files in WEB-INF/lib they will be scanned for SCIs,
fragments and annotations. With absolute-ordering/ you instructs Tomcat
to skip the scanning.




 Regards,
 Violeta



 --
 George Sexton
 *MH Software, Inc.*
 Voice: 303 438 9585
 http://www.mhsoftware.com

[ANN] Apache Tomcat 7.0.55 released

2014-07-29 Thread Violeta Georgieva

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 7.0.55.

Apache Tomcat is an open source software implementation of the Java
Servlet, JavaServer Pages and Java Expression Language technologies.

This release contains a number of bug fixes and improvements compared to
version 7.0.54.

Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-7.0-doc/changelog.html

Note: This version has 4 zip binaries: a generic one and
  three bundled with Tomcat native binaries for Windows operating
  systems running on different CPU architectures.

Note: Use of the JSR-356 Java WebSocket 1.0 implementation requires Java 7.

Note: If you use the APR/native AJP or HTTP connector you *must* upgrade
  to version 1.1.31 or later of the APR/native library.

Downloads:
http://tomcat.apache.org/download-70.cgi

Migration guides from Apache Tomcat 5.5.x and 6.0.x:
http://tomcat.apache.org/migration.html

Re: [ANN] New committer: Felix Schumacher

2014-09-19 Thread Violeta Georgieva

2014-09-19 10:49 GMT+03:00 Rainer Jung rj...@apache.org:

 On behalf of the Tomcat committers I am pleased to announce that
 Felix Schumacher (fschumacher) has been voted in as a new Tomcat
committer.

 Please join me in welcoming him.

Welcome!

Regards
Violeta

 Regards,

 Rainer

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

[ANN] Apache Tomcat 7.0.56 released

2014-10-07 Thread Violeta Georgieva

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 7.0.56.

Apache Tomcat is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Expression Language and Java
WebSocket technologies.

This release contains a number of bug fixes and improvements compared to
version 7.0.55. The notable changes since 7.0.55 include:

- Update the Java WebSocket support to version 1.1 of the Java WebSocket
  specification.
- Add support for the WebSocket permessage-deflate extension.


Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-7.0-doc/changelog.html

Note: This version has 4 zip binaries: a generic one and
  three bundled with Tomcat native binaries for Windows operating
  systems running on different CPU architectures.

Note: Use of the Java WebSocket 1.1 implementation requires Java 7.

Note: If you use the APR/native AJP or HTTP connector you *must* upgrade
  to version 1.1.31 or later of the APR/native library.

Downloads:
http://tomcat.apache.org/download-70.cgi

Migration guides from Apache Tomcat 5.5.x and 6.0.x:
http://tomcat.apache.org/migration.html

- The Apache Tomcat team

[ANN] Apache Tomcat 7.0.57 released

2014-11-14 Thread Violeta Georgieva

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 7.0.57.

Apache Tomcat is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Expression Language and Java
WebSocket technologies.

This release contains a number of bug fixes and improvements compared to
version 7.0.56. The notable changes since 7.0.56 include:


- Update to Tomcat Native Library version 1.1.32 to pick up the Windows
   binaries that are based on OpenSSL 1.0.1j and APR 1.5.1.
- Add support for TLSv1.1 and TLSv1.2 for APR connector. Based upon
   a patch by Marcel Šebek. This feature requires Tomcat Native library
   1.1.32 or later.
- Disable SSLv3 by default for all HTTPS connectors.


Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-7.0-doc/changelog.html

Note: This version has 4 zip binaries: a generic one and
  three bundled with Tomcat native binaries for Windows operating
  systems running on different CPU architectures.

Note: Use of the Java WebSocket 1.1 implementation requires Java 7.

Note: If you use the APR/native AJP or HTTP connector you *must* upgrade
  to version 1.1.32 or later of the APR/native library.

Downloads:
http://tomcat.apache.org/download-70.cgi

Migration guides from Apache Tomcat 5.5.x and 6.0.x:
http://tomcat.apache.org/migration.html

- The Apache Tomcat team

Re: Apache Tomcat Project Information

2014-11-20 Thread Violeta Georgieva

Hi,

2014-11-18 14:52 GMT+02:00 Iago Alonso Alonso infia...@udc.es:

 Hello, we are a group of two students in college and are looking for
information about Apache Tomcat project. We wonder if they could give us
some information about:

You can start here http://tomcat.apache.org/

 - Development methodology, release planning and tools.

Then continues here http://tomcat.apache.org/tools.html

 - Software Quality: Metrics and testing.

and here http://tomcat.apache.org/ci.html and
https://scan.coverity.com/projects/2780

Regards,
Violeta

 Thank you, greetings.

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

[ANN] Apache Tomcat 7.0.59 released

2015-02-09 Thread Violeta Georgieva

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 7.0.59.

Apache Tomcat is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Expression Language and Java
WebSocket technologies.

This release contains a number of bug fixes and improvements compared to
version 7.0.57. The notable changes since 7.0.57 include:


- Session ID Generator is now extensible.


Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-7.0-doc/changelog.html

Note: This version has 4 zip binaries: a generic one and
  three bundled with Tomcat native binaries for Windows operating
  systems running on different CPU architectures.

Note: Use of the Java WebSocket 1.1 implementation requires Java 7.

Note: If you use the APR/native AJP or HTTP connector you *must* upgrade
  to version 1.1.32 or later of the APR/native library.

Downloads:
http://tomcat.apache.org/download-70.cgi

Migration guides from Apache Tomcat 5.5.x and 6.0.x:
http://tomcat.apache.org/migration.html

- The Apache Tomcat team

o.a.c.startup.WebappServiceLoader.load inconsistent behavior when searching for SCI (different loaders when searching for container SCIs)

2015-03-18 Thread Violeta Georgieva

Hi,

I have an issue that I investigate and it led me to the implementation
of org.apache.catalina.startup.WebappServiceLoader.load(ClassT)

So I have two scenarios:
- web application with web fragment inside the archive (WEB-INF/lib)
- web application with functionality of the fragment copied directly to the
WEB-INF classes i.e. there is no web fragment.

In the first scenario we (WebappServiceLoader.load) will search for SCIs in
the web fragment using web app loader and then on row 121 we will switch to
the paren loader and then continue searching the SCIs in other locations.
In the second scenario we will search for SCIs always with the web app
loader.

The problem that I'm investigating is in OSGi environment where the parent
loader of the web app loader does not mean the same as in non OSGi
environment. When there is no web fragment I can find the container SCIs
(e.g. Web Socket implementation), but when there is web fragment I cannot
find the SCIs anymore because of the switch of the loaders.

Can you give me an advice how to overcome this issue?
I'm trying to use as much as possible from Tomcat implementation and to
plug only here and there in order to support OSGi environment.

I'm debugging with sources from Tomcat 7 trunk.

Regards,
Violeta

Re: o.a.c.startup.WebappServiceLoader.load inconsistent behavior when searching for SCI (different loaders when searching for container SCIs)

2015-03-18 Thread Violeta Georgieva

Hi,

2015-03-18 11:35 GMT+02:00 Mark Thomas ma...@apache.org:

 On 18/03/2015 09:00, Violeta Georgieva wrote:
  Hi,
 
  I have an issue that I investigate and it led me to the implementation
  of org.apache.catalina.startup.WebappServiceLoader.load(ClassT)
 
  So I have two scenarios:
  - web application with web fragment inside the archive (WEB-INF/lib)
  - web application with functionality of the fragment copied directly to
the
  WEB-INF classes i.e. there is no web fragment.
 
  In the first scenario we (WebappServiceLoader.load) will search for
SCIs in
  the web fragment using web app loader and then on row 121 we will
switch to
  the paren loader and then continue searching the SCIs in other
locations.
  In the second scenario we will search for SCIs always with the web app
  loader.
 
  The problem that I'm investigating is in OSGi environment where the
parent
  loader of the web app loader does not mean the same as in non OSGi
  environment. When there is no web fragment I can find the container SCIs
  (e.g. Web Socket implementation), but when there is web fragment I
cannot
  find the SCIs anymore because of the switch of the loaders.
 
  Can you give me an advice how to overcome this issue?
  I'm trying to use as much as possible from Tomcat implementation and to
  plug only here and there in order to support OSGi environment.

 Hmm. Either we find a way to patch the WebappServiceLoader so it works
 with non-OSGI and OSGI environments or it looks like you'd have to use a
 custom ContextConfig implementation that used a different
 WebappServiceLoader.

 I've no objections to considering patching - with the usual caveats
 about the final decision coming down to what the actual patch looks like.

 If I have understood you correctly, the problematic line is:
 loader = loader.getParent()

 In the non-OSGI case loader.getParent() is the shared class loader (the
 Tomcat 5.5 class loader docs [1] are probably the better ones to look at
 in this case as it shows the full hierarchy which was collapsed in later
 versions).

 If this line was changed to:
 loader = context.getParentClassLoader()

I tried with quick patches in Tomcat and on my side and with one very basic
scenario and it is working.

I'll test a little bit more but at the moment this is the change that I
made in WebappServiceLoader (based on Tomcat 7 trunk):


Index: java/org/apache/catalina/startup/ContextConfig.java
===
--- java/org/apache/catalina/startup/ContextConfig.java (revision 1667469)
+++ java/org/apache/catalina/startup/ContextConfig.java (working copy)
@@ -1278,7 +1278,7 @@

 // Step 3. Look for ServletContainerInitializer implementations
 if (ok) {
-
 processServletContainerInitializers(context.getServletContext());
+processServletContainerInitializers();
 }

 if  (!webXml.isMetadataComplete() || typeInitializerMap.size() 
0) {
@@ -1567,13 +1567,13 @@
 /**
  * Scan JARs for ServletContainerInitializer implementations.
  */
-protected void processServletContainerInitializers(ServletContext
servletContext) {
+protected void processServletContainerInitializers() {

 ListServletContainerInitializer detectedScis;
 try {
 WebappServiceLoaderServletContainerInitializer loader =
 new WebappServiceLoaderServletContainerInitializer(
-servletContext,
context.getContainerSciFilter());
+context, context.getContainerSciFilter());
 detectedScis = loader.load(ServletContainerInitializer.class);
 } catch (IOException e) {
 log.error(sm.getString(
Index: java/org/apache/catalina/startup/WebappServiceLoader.java
===
--- java/org/apache/catalina/startup/WebappServiceLoader.java (revision
1667469)
+++ java/org/apache/catalina/startup/WebappServiceLoader.java (working copy)
@@ -33,6 +33,8 @@

 import javax.servlet.ServletContext;

+import org.apache.catalina.Context;
+
 /**
  * A variation of Java's JAR ServiceLoader that respects exclusion rules
for
  * web applications.
@@ -57,7 +59,8 @@
 private static final String SERVICES = META-INF/services/;
 private static final Charset UTF8 = Charset.forName(UTF-8);

-private final ServletContext context;
+private final ServletContext servletContext;
+private final Context context;
 private final Pattern containerSciFilterPattern;

 /**
@@ -65,8 +68,9 @@
  *
  * @param context the context to use
  */
-public WebappServiceLoader(ServletContext context, String
containerSciFilter) {
+public WebappServiceLoader(Context context, String containerSciFilter)
{
 this.context = context;
+this.servletContext = context.getServletContext();
 if (containerSciFilter != null  containerSciFilter.length()  0

Re: java.lang.NullPointerException at org.apache.jasper.JspCompilationContext.getTldResourcePath(JspCompilationContext.java:536) when starting Embedded Tomcat Instance

2015-03-16 Thread Violeta Georgieva

Hi,


2015-03-16 15:33 GMT+02:00 Thusitha Thilina Dayaratne thusit...@wso2.com:

 Hi Violeta

 Hi,

 2015-03-16 15:07 GMT+02:00 Thusitha Thilina Dayaratne thusit...@wso2.com
:
 
   ERROR {org.apache.catalina.core.ApplicationDispatcher} -
   Servlet.service() for servlet bridgeservlet threw exception
   java.lang.NullPointerException
   at
  
  
 

org.apache.jasper.JspCompilationContext.getTldResourcePath(JspCompilationContext.java:536)
   at
  
org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:410)
   at org.apache.jasper.compiler.Parser.parseDirective(Parser.java:469)
   at org.apache.jasper.compiler.Parser.parseElements(Parser.java:1430)
   at org.apache.jasper.compiler.Parser.parse(Parser.java:139)
  
   snip/
  
   I can't figure out the reason to get this NullPointerException.
   Can someone help me out?
  
   If we knew which version of Tomcat 8 you were using, someone could
 look
   at the relevant source code to try to figure out what was going on.
   I'm using tomcat version *8.0.20*
 
  Browse to the sourcecode of v8.0.20 of tomcat here:
 
   public TldResourcePath getTldResourcePath(String uri) {
   return getOptions().getTldCache().getTldResourcePath(uri);
   }
  Thanks for the quick response
 
   Obviously either getOptions() or getTldCache() is returning null.
 
  I debug the code as you suggest and found that getTldCache() is null.
  In the code As I understand there are 2 point which set the *tldCache*
   variable
  one is the setTldCache() method and other is
  public static TldCache getInstance(ServletContext servletContext) {
 
  if (servletContext == null) {
  throw new IllegalArgumentException(Localizer.getMessage(
 
 org.apache.jasper.compiler.TldCache.servletContextNull));
  }
  return (TldCache)
  servletContext.getAttribute(SERVLET_CONTEXT_ATTRIBUTE_NAME);
  }



 If you can attach a debugger try to see whether the code below is
invoked:

 org.apache.jasper.servlet.JasperInitializer.onStartup(SetClass?,
 ServletContext) {
 .
 context.setAttribute(TldCache.SERVLET_CONTEXT_ATTRIBUTE_NAME,
 new TldCache(context,
scanner.getUriTldResourcePathMap(),
 scanner.getTldResourcePathTaglibXmlMap()));
 
 }
 I have checked that as well. But that method didn't get hot when I'm
 debugging the source.
 what could be the reason?

You wrote that you are running an embedded Tomcat. Is that true?
In Tomcat 8, Jasper initialization is implemented as a standard
ServletContainderInitializer (check Servlet specification).
So you should ensure
that org.apache.jasper.servlet.JasperInitializer.onStartup is invoked
during web app startup.

Regards,
Violeta

 Thanks
 Regards
 Thusitha

Re: java.lang.NullPointerException at org.apache.jasper.JspCompilationContext.getTldResourcePath(JspCompilationContext.java:536) when starting Embedded Tomcat Instance

2015-03-16 Thread Violeta Georgieva

Hi,

2015-03-16 15:07 GMT+02:00 Thusitha Thilina Dayaratne thusit...@wso2.com:

  ERROR {org.apache.catalina.core.ApplicationDispatcher} -
  Servlet.service() for servlet bridgeservlet threw exception
  java.lang.NullPointerException
  at
 
 

org.apache.jasper.JspCompilationContext.getTldResourcePath(JspCompilationContext.java:536)
  at
  org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:410)
  at org.apache.jasper.compiler.Parser.parseDirective(Parser.java:469)
  at org.apache.jasper.compiler.Parser.parseElements(Parser.java:1430)
  at org.apache.jasper.compiler.Parser.parse(Parser.java:139)
 
  snip/
 
  I can't figure out the reason to get this NullPointerException.
  Can someone help me out?
 
  If we knew which version of Tomcat 8 you were using, someone could
look
  at the relevant source code to try to figure out what was going on.
  I'm using tomcat version *8.0.20*

 Browse to the sourcecode of v8.0.20 of tomcat here:

  public TldResourcePath getTldResourcePath(String uri) {
  return getOptions().getTldCache().getTldResourcePath(uri);
  }
 Thanks for the quick response

  Obviously either getOptions() or getTldCache() is returning null.

 I debug the code as you suggest and found that getTldCache() is null.
 In the code As I understand there are 2 point which set the *tldCache*
  variable
 one is the setTldCache() method and other is
 public static TldCache getInstance(ServletContext servletContext) {

 if (servletContext == null) {
 throw new IllegalArgumentException(Localizer.getMessage(

org.apache.jasper.compiler.TldCache.servletContextNull));
 }
 return (TldCache)
 servletContext.getAttribute(SERVLET_CONTEXT_ATTRIBUTE_NAME);
 }



If you can attach a debugger try to see whether the code below is invoked:

org.apache.jasper.servlet.JasperInitializer.onStartup(SetClass?,
ServletContext) {
.
context.setAttribute(TldCache.SERVLET_CONTEXT_ATTRIBUTE_NAME,
new TldCache(context, scanner.getUriTldResourcePathMap(),
scanner.getTldResourcePathTaglibXmlMap()));

}


Regards,
Violeta


  from this 2 methods I couldn't find any point that setTldCache() is been
 used. So I think getInstance() is the method that is been used.

 Should I manually set the value o tldCache?

 Thanks
 Regards
 /Thusitha

Re: java.lang.NullPointerException at org.apache.jasper.JspCompilationContext.getTldResourcePath(JspCompilationContext.java:536) when starting Embedded Tomcat Instance

2015-03-17 Thread Violeta Georgieva

Hi,

2015-03-17 15:16 GMT+02:00 Thusitha Thilina Dayaratne thusit...@wso2.com:

 Hi
 
  Hi Violeta
 
  Hi,
 
  2015-03-16 15:07 GMT+02:00 Thusitha Thilina Dayaratne 
thusit...@wso2.com
 :
  
ERROR {org.apache.catalina.core.ApplicationDispatcher} -
Servlet.service() for servlet bridgeservlet threw exception
java.lang.NullPointerException
at
   
   
  
 

org.apache.jasper.JspCompilationContext.getTldResourcePath(JspCompilationContext.java:536)
at
   
 org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:410)
at
org.apache.jasper.compiler.Parser.parseDirective(Parser.java:469)
at
org.apache.jasper.compiler.Parser.parseElements(Parser.java:1430)
at org.apache.jasper.compiler.Parser.parse(Parser.java:139)
   
snip/
   
I can't figure out the reason to get this NullPointerException.
Can someone help me out?
   
If we knew which version of Tomcat 8 you were using, someone could
  look
at the relevant source code to try to figure out what was going
on.
I'm using tomcat version *8.0.20*
  
   Browse to the sourcecode of v8.0.20 of tomcat here:
  
public TldResourcePath getTldResourcePath(String uri) {
return getOptions().getTldCache().getTldResourcePath(uri);
}
   Thanks for the quick response
  
Obviously either getOptions() or getTldCache() is returning null.
  
   I debug the code as you suggest and found that getTldCache() is null.
   In the code As I understand there are 2 point which set the *tldCache*
variable
   one is the setTldCache() method and other is
   public static TldCache getInstance(ServletContext servletContext) {
  
   if (servletContext == null) {
   throw new IllegalArgumentException(Localizer.getMessage(
  
  org.apache.jasper.compiler.TldCache.servletContextNull));
   }
   return (TldCache)
   servletContext.getAttribute(SERVLET_CONTEXT_ATTRIBUTE_NAME);
   }
 
 
 
  If you can attach a debugger try to see whether the code below is
 invoked:
 
  org.apache.jasper.servlet.JasperInitializer.onStartup(SetClass?,
  ServletContext) {
  .
  context.setAttribute(TldCache.SERVLET_CONTEXT_ATTRIBUTE_NAME,
  new TldCache(context,
 scanner.getUriTldResourcePathMap(),
  scanner.getTldResourcePathTaglibXmlMap()));
  
  }
  I have checked that as well. But that method didn't get hot when I'm
  debugging the source.
  what could be the reason?

 You wrote that you are running an embedded Tomcat. Is that true?
 In Tomcat 8, Jasper initialization is implemented as a standard
 ServletContainderInitializer (check Servlet specification).
 So you should ensure
 that org.apache.jasper.servlet.JasperInitializer.onStartup is invoked
 during web app startup

 Could someone tell me how can I make sure that this method get call during
 the web app startup?

You didn't tell us whether you are embedding Tomcat or not.
If you are embedding it which jar files from Tomcat distribution you are
using etc.
You can start debugging
with org.apache.catalina.startup.ContextConfig.webConfig()

- processServletContainerInitializers(sContext);

Regards,
Violeta


 Best Regards
 Thusitha

Re: org.apache.jasper.JasperException: The absolute uri: http://tiles.apache.org/tags-tiles cannot be resolved in either web.xml or the jar files deployed with this application

2015-03-19 Thread Violeta Georgieva

Hi,

2015-03-19 5:34 GMT+02:00 Thusitha Thilina Dayaratne thusit...@wso2.com:

 Hi Chris,

 Thanks a lot for the quick response. Please find inline answers.

 On 3/18/15 5:39 AM, Thusitha Thilina Dayaratne wrote:
  I'm in the process of migrating embedded tomcat 7.0.59 application
  to Tomcat 8.0.20. Tomcat is been bundle as a OSGI bundle. First I
  get a NullPointerException when trying to access the server home
  page. I fixed that manually setting an empty TldCache instance in
  the context as follows
 
  [snip]
 
 
  Now it is not throwing the NPE. but instead of that I'm getting
  following exception
 
  org.apache.jasper.JasperException: The absolute uri:
  http://tiles.apache.org/tags-tiles cannot be resolved in either
  web.xml or the jar files deployed with this application at
 

org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:55)

 I
 
 looks like you are missing the Tiles JAR. Is it located in your
 WEB-INF/lib directory?
 These jar files are located in a folder called plugins. We are reading
them
 from our JarScanner

  I'm also using a extended JarScanner as follows

 
  public class CarbonTomcatJarScanner extends StandardJarScanner{

  Without trying to read and understand all this code, can you explain
  why you are using your own JarScanner instead of Tomcat's? Perhaps
  there is a way to do this where you don't need to write your own
  JarScanner.

 According the servlet 3.0 spec, tldScanner classes are picked up
 during web-app load phase from
 the classPath using SPI mechanism. Normal sequence is to scan;
  - WEB-INF/lib
  - parent URL classPath
 However with the BundleClassLoader being the parent classLoader of
 Tomcat web-app classLoder, it fails to pick up
 TLD scanner references reside in plugins directory. That is why we
 have used a our own JarScanner

  It seems that this is relate to JarScanner. Can someone tell me
  what I have done wrong here? Or a way to fix this? Is this occur
  because I set TldCache manually?

 I'm curious as to why the TldCache isn't being set up correctly in the
 first place. In your other recent thread (NPE in
 JspCompilationContext.getTldResourcePath), there were a couple of
 questions from the community that it doesn't look like you have
 answered. Perhaps answering those might help you solve both problems
 at once.
 I'm not so quite sure about that. I manually set the TldCache and manually
 added the JasperInitializer to the StandardContext
 to get rid of the NPE
 I will try to answer the an answered questions in other thread.

You may want to have a look at Eclipse Gemini Web (OSGi Web Container
Reference Implementation)

Regards,
Violeta

 Thanks
 Best Regards
 /Thusitha

Re: Excessive number of blank lines being logged in blocks by org.apache.tomcat.util.digester.Digester

2015-04-01 Thread Violeta Georgieva

Hi,

2015-03-30 10:27 GMT+03:00 Polina Genova polina.gen...@gmail.com:

 Hi,



 Recently I came across an issue with excessive number of blocks of blank
 lines being logged in the catalina output logs.

 This is easily reproducible by simply starting a clean Tomcat 7.0.59
server
 with enabled the following logger configuration

 org.apache.tomcat.util.digester.Digester.level = FINEST

 The result is enormous catalina log file containing plenty of logs like
the
 following:

 --

 Mar 26, 2015 6:12:48 PM org.apache.tomcat.util.digester.Digester
 startElement

 FINE:   Pushing body text '







   '

 Mar 26, 2015 6:12:48 PM org.apache.tomcat.util.digester.Digester
endElement

 FINE:   Popping body text '







   '

 --

 The number of empty lines increases up to hundreds in a single log
message.

 Actually this depends on the number of new lines being accumulated so far
 for the surrounding xml element of the currently processed one.

 For example when processing the default global server.xml, on invocation
of
 the startElement and stopElement of each inner element

 the surrounding ‘Server’ element’s accumulated body is being logged and it
 consists only of new lines, i.e. no meaningful content.

 As the logged information can bring such a large blocks of empty lines and
 no valuable information, I’d like to propose these debug messages to be
 removed.

 Can you think of a specific reason to preserve them?


I checked that and I think that the log messages can be removed as they do
not give any valuable information, only empty rows in the log.

Regards,
Violeta


 Here’s a patch:

 --- Digester.java   (revision 1669608)

 +++ Digester.java(working copy)

 @@ -1047,9 +1047,6 @@



  // Recover the body text from the surrounding element

  bodyText = bodyTexts.pop();

 -if (debug) {

 -log.debug(  Popping body text ' + bodyText.toString() +
');

 -}



  // Fire end events for all relevant rules in reverse order

  if (rules != null) {

 @@ -1252,9 +1249,7 @@



  // Save the body text accumulated for our surrounding element

  bodyTexts.push(bodyText);

 -if (debug) {

 -log.debug(  Pushing body text ' + bodyText.toString() +
');

 -}



 On a closer look of the Digester class, it seems that the whole structure
 of previously accumulated bodyTexts could be removed, for the bodyText
 values being pushed and popped from it

 are used only in the mentioned debug messages.

 So what do you think is the better approach?



 Thanks and regards,

 Polina

Re: Excessive number of blank lines being logged in blocks by org.apache.tomcat.util.digester.Digester

2015-04-01 Thread Violeta Georgieva

Hi,

2015-04-01 14:30 GMT+03:00 Konstantin Kolinko knst.koli...@gmail.com:

 2015-04-01 13:31 GMT+03:00 Violeta Georgieva miles...@gmail.com:
  Hi,
 
  2015-03-30 10:27 GMT+03:00 Polina Genova polina.gen...@gmail.com:
 
  Hi,
 
 
 
  Recently I came across an issue with excessive number of blocks of
blank
  lines being logged in the catalina output logs.
 
  This is easily reproducible by simply starting a clean Tomcat 7.0.59
  server
  with enabled the following logger configuration
 
  org.apache.tomcat.util.digester.Digester.level = FINEST
 
  The result is enormous catalina log file containing plenty of logs like
  the
  following:
 
  --
 
  Mar 26, 2015 6:12:48 PM org.apache.tomcat.util.digester.Digester
  startElement
 
  FINE:   Pushing body text '
 
 
 
 
 
 
 
'
 
  Mar 26, 2015 6:12:48 PM org.apache.tomcat.util.digester.Digester
  endElement
 
  FINE:   Popping body text '
 
 
 
 
 
 
 
'
 
  --
 
  The number of empty lines increases up to hundreds in a single log
  message.
 
  Actually this depends on the number of new lines being accumulated so
far
  for the surrounding xml element of the currently processed one.
 
  For example when processing the default global server.xml, on
invocation
  of
  the startElement and stopElement of each inner element
 
  the surrounding ‘Server’ element’s accumulated body is being logged
and it
  consists only of new lines, i.e. no meaningful content.
 
  As the logged information can bring such a large blocks of empty lines
and
  no valuable information, I’d like to propose these debug messages to be
  removed.
 
  Can you think of a specific reason to preserve them?
 
 
  I checked that and I think that the log messages can be removed as they
do
  not give any valuable information, only empty rows in the log.
 

 1) What about elements with non-empty bodies?
 E.g. web.xml.

 I do not believe that it is all only whitespace.

 Are element bodies also logged elsewhere?

 2) Sometimes people make a mistake misplacing   or forgetting 
 and what they expect to be attributes actually happens to be in body
 of an XML element.

 http://markmail.org/message/uvdwl5dm3rwhyyt5

 3) If someone voluntary turns on debug logging,  one should expect to
 deal with debug information.

 I do not see why that information should be user-friendly. If
 someone is interested in debugging that component, it shall just dump
 what you have.

 4)  One should be able to filter unwanted log messages in
 java.util.logging. (There exists java.util.logging.Filter interface.
 Somewhere should be useful implementations of it.)

1) 2)
Here [1] I described what kind of checks I performed.

3) 4)
I agree, but if the log entry does not give us any information it is
useless.

Regards,
Violeta

[1] http://marc.info/?l=tomcat-devm=142789504501158w=2

 Best regards,
 Konstantin Kolinko

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Erroneous duplicate servlet mapping exception (IllegalArgumentException)

2015-03-05 Thread Violeta Georgieva

Hi,

2015-03-05 1:53 GMT+02:00 Adam Ryan adam.john.r...@gmail.com:

 Hi,

 I had my tomcat webapp running fine (using Tomcat 8.0.9) in Eclipse Luna,
 and I decided to have a play around with the build path. After changing a
 few things and then changing everything back to its previous state, I am
 now getting an IllegalArgumentException:

 The servlets named [api.rest.BaseServlet] and [src.api.rest.BaseServlet]
 are both mapped to the url-pattern [/BaseServlet] which is not permitted

 I understand what the exception is telling me, but I only have one class
 named BaseServlet, which is in the api.rest package. I have no idea why
 src is being prepended to my package name in the second instance above.
 Whatever the reason is, it is causing my Tomcat server to not start up.

 I have defined the BaseServlet class in my web.xml file as follows:

 servlet
 servlet-nameBaseServlet/servlet-name
 servlet-classapi.rest.BaseServlet/servlet-class
 /servlet

 servlet-mapping
 servlet-nameBaseServlet/servlet-name
 url-pattern/BaseServlet/url-pattern
 /servlet-mapping

 But as I said, this used to work until today. I must have not changed
 something back to its original state in my build path, but I can't figure
 out what. I'm hoping I don't have to recreate my project and tomcat server
 just to make this work.

 Any help is appreciated.

You said you changed the build path.
Did you change the sources location?
Did you change the package name?
Do you have WebServlet annotation defined for your servlet?
Check the classes that you are deploying.

Regards,
Violeta

 Thanks,
 Adam

Re: Apache catalina springsource bundle for Apache Tomcat v6.0.43

2015-03-05 Thread Violeta Georgieva

Hi,

2015-03-05 15:31 GMT+02:00 Mark Thomas ma...@apache.org:

On 05/03/2015 10:02, Raghavendra Nilekani wrote:
Hello All

I have a java application where I use Apache catalina springsource OSGI
bundle (

*com.springsource.org.apache.catalina.springsource-6.0.20.S2-r5956.jar*) to
configure and start tomcat and register tomcat as an OSGI service to my
application. Now I have to migrate to tomcat of latest version which has
security vulnerabilities issued fixed (
http://tomcat.apache.org/security-6.html#Fixed_in_Apache_Tomcat_6.0.43).
Looking at Apache Tomcat website, they have released latest version of
tomcat 6.0.43 where they have fixed many of the security
vulnerabilities.
But I see the latest release of Apache catalina springsource bundle is
com.springsource.org.apache.catalina.springsource v6.0.32 (

http://ebr.springsource.com/repository/app/search?query=com.springsource.org.apache.catalina.springsource
).

My questions are

Note: I work for what was SpringSource and is now Pivotal but not on
this particular product.

1) What is the apache tomcat version matches to
com.springsource.org.apache.catalina.springsource v6.0.32. Does it match
Apache Tomcat v6.0.32 ?

That looks like a reasonable assumption. Knowing the folks that were
involved in the OSGI work I'm as sure as I can be that the versions do
line up.

2) I don't see com.springsource.org.apache.catalina.springsource bundle
for
version 6.0.43. What is the plan for springsource to release bundle for
version 6.0.43 ?

There are no plans. The product is no longer developed.

3) Do apache provide any OSGi bundle (including coyote, jasper and other
related bundles), on version 6.0.43 which I can use in my OSGi
container
and register and use tomcat as an OSGi service ?

No. Apache Tomcat does not produce OSGI bundles. You probably want to
look at Virgo from Eclipse.

@Raghavendra Nilekani: Let's continue the discussion in the forum thread
[1] that you've already created several days ago.

Regards,
Violeta

[1] https://www.eclipse.org/forums/index.php/t/1015969/

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: WebappLoader vs WebappClassLoader

2015-04-21 Thread Violeta Georgieva

Hi,

2015-04-21 6:42 GMT+03:00 Thusitha Thilina Dayaratne 
thusithathil...@gmail.com:

 Hi,

  Could someone tell me what is the purpose of having WebappLoader and
  WebappClassLoader in Tomcat?
 WebappLoader is the Tomcat object that a user can configure that
 represents the class loader. It remains the same across web application
 stop/start.

 WebappClassLoader is the actual class loader. Every time the web
 application is started, a new instance is created and used.

  As I understand WebappClassLoader is per web application and
WebAppLoader
 for
  tomcat server instance. Am I wrong?
 Yes.
 Thanks for the quick explanation.
 So it means WebappClassLoader and WebAppLoader both are per web
 application.
 In tomcat 7 we were able to add repository to the class loader using
 WebAppClassLoader.addRepository()

This is replaced in favor of the new resource implementation.
Check this [1] and this [2].

Regards,
Violeta

[1] http://tomcat.apache.org/migration-8.html#Web_application_resources
[2] http://tomcat.apache.org/tomcat-8.0-doc/config/resources.html

 So in Tomcat 8 if we wanna add repositories to the classloader we should
 done that trough the WebAppLoader not with WebAppClassLoader?
 Please correct me if I'm wrong.

 Thanks
 Best Regards

 2015-04-21 1:51 GMT+05:30 Mark Thomas ma...@apache.org:

  On 20/04/2015 14:22, Thusitha Thilina Dayaratne wrote:
   Hi,
  
   Could someone tell me what is the purpose of having WebappLoader and
   WebappClassLoader in Tomcat?
 
  WebappLoader is the Tomcat object that a user can configure that
  represents the class loader. It remains the same across web application
  stop/start.
 
  WebappClassLoader is the actual class loader. Every time the web
  application is started, a new instance is created and used.
 
   As I understand WebappClassLoader is per web application and
  WebAppLoader for
   tomcat server instance. Am I wrong?
 
  Yes.
 
  Mark
 
 
  -
  To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
  For additional commands, e-mail: users-h...@tomcat.apache.org
 
 


 --

Re: userfriendly failed client authentification

2015-05-08 Thread Violeta Georgieva

Hello,

2015-05-07 20:54 GMT+03:00 Johannes jo...@posteo.de:



 Hello.

 I'm using Tomcat 7.0.with Java 7.0.
 I'm trying to create a webapp with needs a client certifiacte
 authentification.
 Normal client certifiacte authentfication works well and I can compute
 the desired certificate data. The clientauth parameter in the https
 connector is set to false. In my webapp is a security-constraint
 registred for a url space, like  /secure/*.

 If authentifications fails, a ugly browser error page occurs. A new
 authentification try can only be attempt after reopen the browser.

 I already noticed setting server wide clientauth to want, I receive a
 tomcat 401 http error page (which can be customized) if no client
 certificate was found on a protected resource. But entering a bad
 passphrase shows a ugly browser error page again.

 Is there a way to deal with that? I believe the user acceptance will be
 low with that behavior.

Consider providing your own error pages thus you can setup them with you
company branding.

Best Regards,
Violeta

 Best regards Johannes.

[ANN] Apache Tomcat 7.0.62 released

2015-05-16 Thread Violeta Georgieva

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 7.0.62.

Apache Tomcat is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Expression Language and Java
WebSocket technologies.

This release contains a number of bug fixes and improvements compared to
version 7.0.61.

Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-7.0-doc/changelog.html

Note: This version has 4 zip binaries: a generic one and
  three bundled with Tomcat native binaries for Windows operating
  systems running on different CPU architectures.

Note: Use of the Java WebSocket 1.1 implementation requires Java 7.

Note: If you use the APR/native AJP or HTTP connector you *must* upgrade
  to version 1.1.33 or later of the APR/native library.

Downloads:
http://tomcat.apache.org/download-70.cgi

Migration guides from Apache Tomcat 5.5.x and 6.0.x:
http://tomcat.apache.org/migration.html

- The Apache Tomcat team

[ANN] Apache Tomcat 7.0.61 released

2015-04-11 Thread Violeta Georgieva

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 7.0.61.

Apache Tomcat is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Expression Language and Java
WebSocket technologies.

This release contains a number of bug fixes and improvements compared to
version 7.0.59. The notable changes since 7.0.59 include:


- Add support for Java 8 JSSE server-preferred TLS cipher suite ordering.
  This feature requires Java 8.
- Update to Tomcat Native Library version 1.1.33 to pick up the Windows
  binaries that are based on OpenSSL 1.0.1m and APR 1.5.1.
- Implement a new feature for AJP connectors - Tomcat Authorization. If
  enabled Tomcat, will take an authenticated user name from the AJP
  protocol and use the appropriate Realm for the request to authorize
  (i.e. add roles) to that user.
- Update the Eclipse JDT compiler to version 4.4.2.


Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-7.0-doc/changelog.html

Note: This version has 4 zip binaries: a generic one and
  three bundled with Tomcat native binaries for Windows operating
  systems running on different CPU architectures.

Note: Use of the Java WebSocket 1.1 implementation requires Java 7.

Note: If you use the APR/native AJP or HTTP connector you *must* upgrade
  to version 1.1.33 or later of the APR/native library.

Downloads:
http://tomcat.apache.org/download-70.cgi

Migration guides from Apache Tomcat 5.5.x and 6.0.x:
http://tomcat.apache.org/migration.html

- The Apache Tomcat team

Re: How to access JNDI Directory Context in Tomcat 8

2015-04-06 Thread Violeta Georgieva

Hi,

2015-04-06 14:33 GMT+03:00 Thusitha Thilina Dayaratne thusit...@wso2.com:

Is there a Tomcat provided URLStreamHandlerFactory for JNDI in tomcat
8.0.20?
I tried

TomcatURLStreamHandlerFactory.getInstance().createURLStreamHandler(jndi);

jndi schema is removed in Tomcat 8. You may want to check this discussion
[1].

Regards,
Violeta

[1] http://marc.info/?t=13790884487r=1w=2

But that returns null.

Thanks
Best Regards
/Thusitha

On Wed, Mar 25, 2015 at 2:48 PM, Thusitha Thilina Dayaratne
thusit...@wso2.com wrote:

Hi Mark,

Thanks all for responses. But what I actually want is to register a
URLStreamHandlerService for JNDI

Finally. More than 2 weeks since the first e-mail in this thread the
list members know what it is you are actually trying to do.

You want:

http://tomcat.apache.org/tomcat-8.0-doc/api/org/apache/catalina/webresources/TomcatURLStreamHandlerFactory.html
Thanks a lot for the quick response and I'm really sorry for the delay
and
any inconvenience caused due to that

Best Regards
/Thusitha

On Wed, Mar 25, 2015 at 2:28 PM, Mark Thomas ma...@apache.org wrote:

On 25/03/2015 08:14, Thusitha Thilina Dayaratne wrote:
snip/

Thanks all for responses. But what I actually want is to register a
URLStreamHandlerService for JNDI

Finally. More than 2 weeks since the first e-mail in this thread the
list members know what it is you are actually trying to do.

You want:

http://tomcat.apache.org/tomcat-8.0-doc/api/org/apache/catalina/webresources/TomcatURLStreamHandlerFactory.html

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

--
Thusitha Dayaratne
Software Engineer
WSO2 Inc. - lean . enterprise . middleware | wso2.com

Mobile +94712756809
Blog alokayasoya.blogspot.com
Abouthttp://about.me/thusithathilina

--
Thusitha Dayaratne
Software Engineer
WSO2 Inc. - lean . enterprise . middleware | wso2.com

Mobile +94712756809
Blog alokayasoya.blogspot.com
Abouthttp://about.me/thusithathilina

Re: Excessive number of blank lines being logged in blocks by org.apache.tomcat.util.digester.Digester

2015-04-01 Thread Violeta Georgieva

Hi,

2015-04-01 17:01 GMT+03:00 Violeta Georgieva miles...@gmail.com:

 Hi,


 2015-04-01 14:30 GMT+03:00 Konstantin Kolinko knst.koli...@gmail.com:
 
  2015-04-01 13:31 GMT+03:00 Violeta Georgieva miles...@gmail.com:
   Hi,
  
   2015-03-30 10:27 GMT+03:00 Polina Genova polina.gen...@gmail.com:
  
   Hi,
  
  
  
   Recently I came across an issue with excessive number of blocks of
blank
   lines being logged in the catalina output logs.
  
   This is easily reproducible by simply starting a clean Tomcat 7.0.59
   server
   with enabled the following logger configuration
  
   org.apache.tomcat.util.digester.Digester.level = FINEST
  
   The result is enormous catalina log file containing plenty of logs
like
   the
   following:
  
   --
  
   Mar 26, 2015 6:12:48 PM org.apache.tomcat.util.digester.Digester
   startElement
  
   FINE:   Pushing body text '
  
  
  
  
  
  
  
 '
  
   Mar 26, 2015 6:12:48 PM org.apache.tomcat.util.digester.Digester
   endElement
  
   FINE:   Popping body text '
  
  
  
  
  
  
  
 '
  
   --
  
   The number of empty lines increases up to hundreds in a single log
   message.
  
   Actually this depends on the number of new lines being accumulated
so far
   for the surrounding xml element of the currently processed one.
  
   For example when processing the default global server.xml, on
invocation
   of
   the startElement and stopElement of each inner element
  
   the surrounding ‘Server’ element’s accumulated body is being logged
and it
   consists only of new lines, i.e. no meaningful content.
  
   As the logged information can bring such a large blocks of empty
lines and
   no valuable information, I’d like to propose these debug messages to
be
   removed.
  
   Can you think of a specific reason to preserve them?
  
  
   I checked that and I think that the log messages can be removed as
they do
   not give any valuable information, only empty rows in the log.
  
 
  1) What about elements with non-empty bodies?
  E.g. web.xml.
 
  I do not believe that it is all only whitespace.
 
  Are element bodies also logged elsewhere?
 
  2) Sometimes people make a mistake misplacing   or forgetting 
  and what they expect to be attributes actually happens to be in body
  of an XML element.
 
  http://markmail.org/message/uvdwl5dm3rwhyyt5
 
  3) If someone voluntary turns on debug logging,  one should expect to
  deal with debug information.
 
  I do not see why that information should be user-friendly. If
  someone is interested in debugging that component, it shall just dump
  what you have.
 
  4)  One should be able to filter unwanted log messages in
  java.util.logging. (There exists java.util.logging.Filter interface.
  Somewhere should be useful implementations of it.)

 1) 2)
 Here [1] I described what kind of checks I performed.

 3) 4)
 I agree, but if the log entry does not give us any information it is
useless.

My extensive testing shows that there are only whitespaces.
As there were concerns in the previous messages, my proposals are:
1) Either we can keep the debug messages and 'trim' the 'bodyText' that
will be printed.
2) Or I can revert the whole change.

What do you think?

Regards,
Violeta

 Regards,
 Violeta

 [1] http://marc.info/?l=tomcat-devm=142789504501158w=2

  Best regards,
  Konstantin Kolinko
 
  -
  To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
  For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat Valve doing Request.getParameter() consumes the stream

2015-05-29 Thread Violeta Georgieva

Hi,

2015-05-28 22:44 GMT+03:00 Teunissen,Peter peter.teunis...@cerner.com:

 (Tomcat 7)

 I am writing a Valve that does a getParameter on the Request. At the end
of the Valve/Filter chain is a servlet that calls
HttpServletRequest.getReader() returning an empty buffer (because the Valve
consumed it).

 I tried hacking a wrapper for the Request together and pass that into the
getNext().invoke , but not much luck yet (seems to be some state in the
underlying coyoteStream/Request/Inputbuffer)

 I can't imagine I'm the first to encounter this and yet I can't find a
good wrapper example on the internet.

 Anybody better suggestions?

You may want to check this enhancement [1].

Regards,
Violeta

[1] https://bz.apache.org/bugzilla/show_bug.cgi?id=45014


 CONFIDENTIALITY NOTICE This message and any included attachments are from
Cerner Corporation and are intended only for the addressee. The information
contained in this message is confidential and may constitute inside or
non-public information under international, federal, or state securities
laws. Unauthorized forwarding, printing, copying, distribution, or use of
such information is strictly prohibited and may be unlawful. If you are not
the addressee, please promptly delete this message and notify the sender of
the delivery error by e-mail or you may call Cerner's corporate offices in
Kansas City, Missouri, U.S.A at (+1) (816)221-1024.

Re: Strange JSP compilation issues in tomcat 7 and 8

2015-07-06 Thread Violeta Georgieva

Hi,

2015-07-06 16:20 GMT+03:00 p...@kuruma.co.uk:

 I was really hoping that there would be something tomcat related in the
 WEB-INF\lib folder but nothing, they are all marked as provided in the pom
 file.

Another thing that you can check is that you do not pack ECJ library or in
the Tomcat lib you do not have two versions for ECJ library.

Regards,
Violeta

 There was a mistake in my original post, in tomcat 8.0.23 my application
 does not work with jdk's 1.7.0_09 or 1.8.0_11 so basically it doesnt work
 at all in 8.023 with or without the ## in the war file name.

 It seems like tomcat is just unable to compile jsp files in this version.

 Is there anything else I can check or do? I have seen some people say they
 edited the conf/web.xml for the jsp servlet entry, I tried setting the
 params to 1.7 for compilerSourceVM and compilerTargetVM but this had no
 effect.

 I am pretty stuck as the tomcat page
 http://tomcat.apache.org/whichversion.html seems to imply everything is
 compatible??

 On Mon, July 6, 2015 1:44 am, Felix Schumacher wrote:

  Am 4. Juli 2015 11:04:13 MESZ, schrieb p...@kuruma.co.uk:
 
  I am working on a spring\tiles application which I have been deploying
  to tomcat7 (7.0.32 and 7.0.53) and tomcat8 (8.2.0.23) and my war files
  are built with maven using jdk1.7.0_09.
 
  In my pom file I declare the final name using the ## syntax that I was
  told before on this mailing list would ensure that when deploying to
  tomcat that I would not get the version name as part of the context and
   so could just use the web app name in the url and in the past this has
  worked ok for me.
 
  finalName${finalName}##${project.version}/finalName
 
 
  So my war file build with a name like mywebapp##0.0.0.war, I deploy
  this with tomcat manager or manually and it deploys ok, no errors I can
  see on deployment.
 
  However when I try to access any pages I get jsp compilation issues, in
   both versions of tomcat 7 I get this error:
 
  org.springframework.web.util.NestedServletException: Request processing
   failed; nested exception is
  org.apache.tiles.request.render.CannotRenderException: ServletException
   including path '/WEB-INF/tiles/layout.jsp'.
 
  org.apache.jasper.JasperException: Unable to compile class for JSP:
 
 
  An error occurred at line: 1 in the generated java file
  The type java.util.Map$Entry cannot be resolved. It is indirectly
  referenced from required .class files
 
  I have seen similar errors on maven based projects, when the jsp api lib
  was put into WEB-INF/lib/. Check your libs in that location. Remove any
  servlet specific libs from there.
 
  Regards,
  Felix
 
 
  And when deploying to tomcat8 I get this error:
 
 
  javax.servlet.ServletException: Could not resolve view with name
  'base/dashboard/view' in servlet with name 'appServlet'
 
 
  If I deploy the war files without the ## in the name so just like
  mywebapp.war then they deploy and run fine in both versions of tomcat7
  and tomcat8.
 
  Does anybody have any idea what could be the problem?
 
 
  I have in the past deployed war files with the ## in the web app name
  without any issues and whilst they didnt use Spring and Apache Tiles
they
   did use a lot of jsp's and this didnt cause any issues.
 
  I should also point out that the web app with the problems contains all
   the display\front end but the back end which has no jsps or tiles but
  is still a spring web app but only provides rest apis for the web front
  end to call does not have any issues with the ## in the war file name
  and I have not had to change this wars name at all whilst doing this
  testing.
 
  Its odd in that I can start tomcat with the ## and get an error, stop
  it, clean down the work directory and then remove rhe ## from the war
  name and restart tomcat and it works now.
 
 
  -
  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: Tomcat, REMOTE_USER, getRemoteUser()

2015-07-23 Thread Violeta Georgieva

Hi,

2015-07-23 21:54 GMT+03:00 John Baker jba...@dryfish.org.uk:

 Hello,

 I note the HTTP connector does the following when
 Request.getRemoteUser() is called:

 public String getRemoteUser() {
 if (userPrincipal == null) {
 return null;
 }
 return userPrincipal.getName();
 }

 I understand what it's trying to do but it's not consistent with the AJP
 adapter and doesn't make it helpful to interact with upstream reverse
 proxies setting the username as a header (ie REMOTE_USER). Would it be
 possible to change the implementation to this:

 public String getRemoteUser() {
 String user = userPrincipal.getName();
 if (userPrincipal == null)
 user= getHeader(REMOTE_USER);
 return user;
 }

 Or even better, allow the REMOTE_USER header name to be set via a
 configuration value? This seems much more consistent with the AJP
 adapter that does pick up REMOTE_USER (sent by the ajp module) and
 avoids users having to retrieve a header from the request.


You didn't specify any Tomcat version.

Check this feature [1] - tomcatAuthentication/tomcatAuthorization

Regards,
Violeta
[1]
http://tomcat.apache.org/tomcat-7.0-doc/config/ajp.html#Standard_Implementations

 Thanks


 John

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat-7.0.61 and SFlow_Valve.jar issue

2015-07-23 Thread Violeta Georgieva

Hi,

2015-07-23 21:36 GMT+03:00 Sergey svin...@apple.com:

 We updated Tomcat from 7.0.10 to 7.0.61.
 In previous version we collected Tomcat metrics using Sflow_Valve.jar
module.
 Now it looks like Coyote Connector can't call Request.getBytesRead()
method.
 Here is the Catalina log error:

 org.apache.coyote.http11.AbstractHttp11Processor process
 SEVERE: Error processing request
 java.lang.NoSuchMethodError: org.apache.coyote.Request.getBytesRead()I
 at com.sflow.catalina.SFlowValve.xdrFlowSample(SFlowValve.java:341)
 at com.sflow.catalina.SFlowValve.sampleRequest(SFlowValve.java:438)
 at com.sflow.catalina.SFlowValve.invoke(SFlowValve.java:320)
 at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:950)
 at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
 at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:423)
 at
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1079)
 at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:620)
 at
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:318)
 at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
 at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
 at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
 at java.lang.Thread.run(Unknown Source)

 Did anybody have this issue?

Check the change log [1].
The signature of the method was changed as part of the fix for bug 57581

Regards,
Violeta

[1] http://tomcat.apache.org/tomcat-7.0-doc/changelog.html#Tomcat 7.0.60
(violetagg)


 Thanks!
 Sergey


 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat 8 - Manager Deploy

2015-07-13 Thread Violeta Georgieva

Hi,

2015-07-13 14:48 GMT+03:00 theo.swe...@avios.com:

 Hello Again - I've ran a new test with a sample war file downloaded from -

 https://tomcat.apache.org/tomcat-6.0-doc/appdev/sample/sample.war

 The war is renamed as sample-1.0##v1.0.0.war

 This time the war deploys and starts but it doesn't honour the version
 number given in the path -

 curl -v --upload-file /usr/share/tomcat/installs/sample-1.0##v1.0.0.war -X
 PUT 
 http://username:password@localhost
:10080/manager/text/deploy?path=/sample-1.0##v1.0.0update=true
 


If you need to specify a version that use the correct syntax:

http://tomcat.apache.org/tomcat-8.0-doc/manager-howto.html#Supported_Manager_Commands

path - The context path (including the leading slash) of the web
application you are dealing with. To select the ROOT web application,
specify /. NOTE: It is not possible to perform administrative commands on
the Manager application itself.
version - The version of this web application as used by the parallel
deployment feature,

Regards,
Violeta

 View running webapps -

 $ curl -X GET http://tcsct:cbiw2PXB@localhost:10080/manager/text/list
 OK - Listed applications for virtual host localhost
 /manager:running:4:manager
 /sample-1.0:running:0:sample-1.0

 Instead I would expect to see -

 $ curl -X GET http://tcsct:cbiw2PXB@localhost:10080/manager/text/listOK -
 Listed applications for virtual host localhost
 /manager:running:4:manager
 /sample-1.0:running:0:sample-1.0##v1.0.0

 Is there a reason why the version number is being omitted?




 From:   Theo Sweeny/LGW/MILEAGE
 To: Tomcat Users List users@tomcat.apache.org,
 Date:   13/07/2015 08:33
 Subject:Re: Tomcat 8 - Manager Deploy


 Hello Konstantin - thank you for the reply.

 So your deployment (upload) was successful,  but the application itself is
 broken and failed to start.

 If I take the same application and deploy it using deployOnStartup, it
 deploys and starts without issue. This removes the possibility of there
 being an issue with the war file.

 Here are the Catalina and Localhost logs -

 logs/catalina.2015-07-10.log:10-Jul-2015 11:20:54.560 INFO
 [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployWAR
 Deploying web application archive
 /opt/tomcat/webapps/address-information-ds-1.0.war

 logs/catalina.2015-07-10.log:10-Jul-2015 11:20:54.568 SEVERE
 [localhost-startStop-1]
 org.apache.catalina.startup.ContextConfig.beforeStart Exception fixing
 docBase for context [/address-information-ds-1.0]

 logs/catalina.2015-07-10.log:10-Jul-2015 11:20:54.571 SEVERE
 [localhost-startStop-1]
 org.apache.catalina.core.ContainerBase.addChildInternal
 ContainerBase.addChild: start:

 logs/catalina.2015-07-10.log:10-Jul-2015 11:20:54.572 SEVERE
 [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployWAR
 Error deploying web application archive
 /opt/tomcat/webapps/address-information-ds-1.0.war

 logs/catalina.2015-07-10.log:10-Jul-2015 11:20:54.573 INFO
 [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployWAR
 Deployment of web application archive
 /opt/tomcat/webapps/address-information-ds-1.0.war has finished in 13 ms

 logs/catalina.2015-07-10.log:10-Jul-2015 11:20:54.574 INFO
 [localhost-startStop-1]
 org.apache.catalina.startup.HostConfig.deployDirectory Deploying web
 application directory /opt/tomcat/webapps/ROOT

 logs/catalina.2015-07-10.log:10-Jul-2015 11:20:55.031 INFO
 [localhost-startStop-1]
 org.apache.catalina.startup.HostConfig.deployDirectory Deployment of web
 application directory /opt/tomcat/webapps/ROOT has finished in 456 ms

 logs/catalina.2015-07-10.log:10-Jul-2015 11:20:55.031 INFO
 [localhost-startStop-1]
 org.apache.catalina.startup.HostConfig.deployDirectory Deploying web
 application directory /opt/tomcat/webapps/host-manager

 logs/catalina.2015-07-10.log:10-Jul-2015 11:20:55.544 INFO
 [localhost-startStop-1]
 org.apache.catalina.startup.HostConfig.deployDirectory Deployment of web
 application directory /opt/tomcat/webapps/host-manager has finished in 513
 ms

 logs/catalina.2015-07-10.log:10-Jul-2015 11:20:55.545 INFO
 [localhost-startStop-1]
 org.apache.catalina.startup.HostConfig.deployDirectory Deploying web
 application directory /opt/tomcat/webapps/manager

 logs/catalina.2015-07-10.log:10-Jul-2015 11:20:55.973 INFO
 [localhost-startStop-1]
 org.apache.catalina.startup.HostConfig.deployDirectory Deployment of web
 application directory /opt/tomcat/webapps/manager has finished in 427 ms

 logs/catalina.2015-07-10.log:10-Jul-2015 11:20:55.980 INFO [main]
 org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler
 [http-nio-10080]

 logs/catalina.2015-07-10.log:10-Jul-2015 11:20:55.990 INFO [main]
 org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler
 [ajp-nio-10009]

 logs/catalina.2015-07-10.log:10-Jul-2015 11:20:55.990 INFO [main]
 org.apache.catalina.startup.Catalina.start Server startup in 58884 ms

 logs/localhost.2015-07-10.log:10-Jul-2015 11:20:42.779 INFO

Re: CsrfPreventionFilter for REST

2015-10-22 Thread Violeta Georgieva

Hi,

2015-09-17 10:55 GMT+03:00 Christoph Nenning :
>
> Violeta,
>
>
>
> > > > Hello,
> > > >
> > > > ** **
> > > >
> > > > *Background information:*
> > > >
> > > > We are trying to protect our RESTful
> > > > APIs
> > > > from
> > > > CSRF attack.
> > > >
> > > > The current Tomcat’s CSRF protection filter provides proper
> protection
> > for
> > > > web resources that are supposed to be accessed via some sort of
> > navigation
> > > > i.e. there’s an entry point which points to them (for example
> include
> > > > links/post forms to them) . With REST APIs you do not have such
> entry
> > > > points as the requests are done independently from each other.  We
> are
> > > > interested do you consider supporting  CSRF protection for RESTful
> > APIs?
> > > >
> > > > ** **
> > > >
> > > > *Example attack:*
> > > >
> > > > Here is an example how to reproduce CSRF attack of RESTful APIs
> using
> > the
> > > > attached apps:
> > > >
> > > >
> > > >1. Check customers initial state:
> > > >http://localhost:8080/restDemo/services/customers/  + login with
> > > >tomcat/tomcat
> > > >2.  **In the same browser open attacker’s app:
> > > >http://localhost:8080/XSRFAttackerApp/
> > > >
> > > > **
> > > >
> > > > Behind the scenes request 2. takes advantage of your credentials
> stored
> > in
> > > > the browser and makes attacking POST request to a state changing
> > operation
> > > > http://localhost:8080/restDemo/services/customers/removeFirst on
> your
> > > > behalf. After that the customer list is empty.
> > > >
> > > > ** **
> > > >
> > > > The problem is that if we use the CSRF filter to protect this API
> > > > /services/customers/removeFirst, this URL is then always served with
> > *403
> > > > Forbidden* (due to the missing csrf token).  In fact  the REST API
> > becomes
> > > > unusable.
> > > >
> > > > ** **
> > > >
> > > > *Research:*
> > > >
> > > > We’ve made some research on the topic and it seems that there is no
> > > > absolutely secure and at the same time clear stateless solution.
> Since
> > it
> > > > is possible for an attacker to insert  custom headers in the
> attacking
> > > > requests, the validation over header presence is not secure
> enough.
> > > >
> > >
> > > The ability to insert headers (or tokens in the request string as
> > > Tomcat's CSRF filter requires) is irrelevant, because  the attacker
> > > has to know the exact token value and the value is random.
> > >
> > > If you are constantly receiving 403 on your POST requests it means
> > > that you are requesting wrong URL (one that does not contain the CSRF
> > > token) or your requests are not a part of the session.
> > >
> > >
> > > > The only stable solution is again based on Synchronizer Token
> > > > Pattern<
> > https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%
> > 29_Prevention_Cheat_Sheet
> > >
> > > > but
> > > > instead of encoded in URLs, the csrf token value can be transferred
> from
> > > > and to the client through a custom csrf token header.  The rest csrf
> >  token
> > > > value needs to be stored in some sort of state on client and server
> > side.
> > > > In addition REST clients need to adopt this csrf token transfer
> > mechanism.**
> > > > **
> > > >
> > > > *Proposal:*
> > > >
> > > > You can find on the link
> > > > https://docs.google.com/open?id=0B-HUwAvkRIKJTVViWUFkNFl6alU , the
> > > > CsrfPreventionFilter extended so that it is able to successfully
> protect
> > > > state changing REST requests. They are validated based on the
> > > > “X-CSRF-Token” header (the header name is configurable).
> > > >
> > > > (...)
> > > >
> > >
> > > The main task of Tomcat's CSRFProtectionFilter is to protect the
> > > Manager application. The application does not use XMLHttpRequest so it
> > > cannot set the headers.
> > > So I see no point in implementing support for passing the token value
> > > in a header, as there is no use for it. Is there enough API available
> > > to extend the filter in a subclass to cover your specific use case?
> >
> > I would like to know whether there is an interest for such filter as
> part
> > of the filters that Tomcat provides by default to its users.
> >
>
>
> Yes, it would be very interesting if tomcat would provide such a filter!

You can take a look at the sources in trunk.

Regards,
Violeta

>
> Regards,
> Christoph
>
>
>
>
>
>
>
> > Thanks and Regards,
> > Violeta
> >
> > > Note that CSRF protection has some specific task. It would not protect
> > > you if an attacker is able to request the "welcome" page and parse it
> > > to extract the token. It would not protect you if you are using
> > > non-secured HTTP and an attacker is able to sniff network traffic.
> > >
> > > Best regards,
> > > Konstantin Kolinko
> > >
> > > -
> > > To unsubscribe, e-mail:

Re: [ANN] New committer: Martin Grigorov

2015-10-26 Thread Violeta Georgieva

2015-10-26 16:35 GMT+02:00 Mark Thomas :
>
> On behalf of the Tomcat committers I am pleased to announce that
> Martin Grigorov (mgrigorov) has been voted in as a new Tomcat committer.
>
> Please join me in welcoming him.

Welcome!

Regards,
Violeta

> Regards,
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>

[ANN] Apache Tomcat 7.0.65 released

2015-10-21 Thread Violeta Georgieva

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 7.0.65.

Apache Tomcat is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Expression Language and Java
WebSocket technologies.

This release contains a number of bug fixes and improvements compared to
version 7.0.64. The notable changes since 7.0.64 include:


- Add a web application class loader implementation that supports the
parallel
  loading of web application classes. Use of this feature requires a Java 7
or
  later JRE


Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-7.0-doc/changelog.html

Note: This version has 4 zip binaries: a generic one and
  three bundled with Tomcat native binaries for Windows operating
  systems running on different CPU architectures.

Note: Use of the Java WebSocket 1.1 implementation requires Java 7.

Note: If you use the APR/native AJP or HTTP connector you *must* upgrade
  to version 1.1.33 or later of the APR/native library.

Downloads:
http://tomcat.apache.org/download-70.cgi

Migration guides from Apache Tomcat 5.5.x and 6.0.x:
http://tomcat.apache.org/migration.html

Enjoy

The Apache Tomcat team

[ANN] Apache Tomcat 7.0.63 released

2015-07-07 Thread Violeta Georgieva

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 7.0.63.

Apache Tomcat is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Expression Language and Java
WebSocket technologies.

This release contains a number of bug fixes and improvements compared to
version 7.0.62. The notable changes since 7.0.62 include:


- Added a workaround for SPNEGO authentication and a JRE regression in
  Java 8 update 40 onwards
- Added the new HttpHeaderSecurityFilter
- Extended support for the Web Socket permessage-deflate extension to
  the client implementation


Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-7.0-doc/changelog.html

Note: This version has 4 zip binaries: a generic one and
  three bundled with Tomcat native binaries for Windows operating
  systems running on different CPU architectures.

Note: Use of the Java WebSocket 1.1 implementation requires Java 7.

Note: If you use the APR/native AJP or HTTP connector you *must* upgrade
  to version 1.1.33 or later of the APR/native library.

Downloads:
http://tomcat.apache.org/download-70.cgi

Migration guides from Apache Tomcat 5.5.x and 6.0.x:
http://tomcat.apache.org/migration.html

Enjoy

The Apache Tomcat team

[ANN] Apache Tomcat 7.0.64 released

2015-08-26 Thread Violeta Georgieva

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 7.0.64.

Apache Tomcat is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Expression Language and Java
WebSocket technologies.

This release contains a number of bug fixes and improvements compared to
version 7.0.63. The notable changes since 7.0.63 include:


- Avoid an NPE when adding POJO WebSocket endpoints programmatically
- Improved handling of async timeouts
- Facilitate weaving by allowing ClassFileTransformer to be added to
  WebappClassLoader


Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-7.0-doc/changelog.html

Note: This version has 4 zip binaries: a generic one and
  three bundled with Tomcat native binaries for Windows operating
  systems running on different CPU architectures.

Note: Use of the Java WebSocket 1.1 implementation requires Java 7.

Note: If you use the APR/native AJP or HTTP connector you *must* upgrade
  to version 1.1.33 or later of the APR/native library.

Downloads:
http://tomcat.apache.org/download-70.cgi

Migration guides from Apache Tomcat 5.5.x and 6.0.x:
http://tomcat.apache.org/migration.html

Enjoy

The Apache Tomcat team

Re: CsrfPreventionFilter for REST

2015-09-16 Thread Violeta Georgieva

Hi,

2012-09-26 12:21 GMT+03:00 Konstantin Kolinko <knst.koli...@gmail.com>:
>
> 2012/9/22 Violeta Georgieva <violet...@apache.org>:
> > Hello,
> >
> > ** **
> >
> > *Background information:*
> >
> > We are trying to protect our RESTful
> > APIs<http://en.wikipedia.org/wiki/Representational_state_transfer>
> > from
> > CSRF attack.
> >
> > The current Tomcat’s CSRF protection filter provides proper protection
for
> > web resources that are supposed to be accessed via some sort of
navigation
> > i.e. there’s an entry point which points to them (for example include
> > links/post forms to them) . With REST APIs you do not have such entry
> > points as the requests are done independently from each other.  We are
> > interested do you consider supporting  CSRF protection for RESTful
APIs?
> >
> > ** **
> >
> > *Example attack:*
> >
> > Here is an example how to reproduce CSRF attack of RESTful APIs using
the
> > attached apps:
> >
> >
> >1. Check customers initial state:
> >http://localhost:8080/restDemo/services/customers/  + login with
> >tomcat/tomcat
> >2.  **In the same browser open attacker’s app:
> >http://localhost:8080/XSRFAttackerApp/
> >
> > **
> >
> > Behind the scenes request 2. takes advantage of your credentials stored
in
> > the browser and makes attacking POST request to a state changing
operation
> > http://localhost:8080/restDemo/services/customers/removeFirst on your
> > behalf. After that the customer list is empty.
> >
> > ** **
> >
> > The problem is that if we use the CSRF filter to protect this API
> > /services/customers/removeFirst, this URL is then always served with
*403
> > Forbidden* (due to the missing csrf token).  In fact  the REST API
becomes
> > unusable.
> >
> > ** **
> >
> > *Research:*
> >
> > We’ve made some research on the topic and it seems that there is no
> > absolutely secure and at the same time clear stateless solution. Since
it
> > is possible for an attacker to insert  custom headers in the attacking
> > requests, the validation over header presence is not secure enough.
> >
>
> The ability to insert headers (or tokens in the request string as
> Tomcat's CSRF filter requires) is irrelevant, because  the attacker
> has to know the exact token value and the value is random.
>
> If you are constantly receiving 403 on your POST requests it means
> that you are requesting wrong URL (one that does not contain the CSRF
> token) or your requests are not a part of the session.
>
>
> > The only stable solution is again based on Synchronizer Token
> > Pattern<
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet
>
> > but
> > instead of encoded in URLs, the csrf token value can be transferred from
> > and to the client through a custom csrf token header.  The rest csrf
 token
> > value needs to be stored in some sort of state on client and server
side.
> > In addition REST clients need to adopt this csrf token transfer
mechanism.**
> > **
> >
> > *Proposal:*
> >
> > You can find on the link
> > https://docs.google.com/open?id=0B-HUwAvkRIKJTVViWUFkNFl6alU , the
> > CsrfPreventionFilter extended so that it is able to successfully protect
> > state changing REST requests. They are validated based on the
> > “X-CSRF-Token” header (the header name is configurable).
> >
> > (...)
> >
>
> The main task of Tomcat's CSRFProtectionFilter is to protect the
> Manager application. The application does not use XMLHttpRequest so it
> cannot set the headers.
> So I see no point in implementing support for passing the token value
> in a header, as there is no use for it. Is there enough API available
> to extend the filter in a subclass to cover your specific use case?

I would like to know whether there is an interest for such filter as part
of the filters that Tomcat provides by default to its users.

Thanks and Regards,
Violeta

> Note that CSRF protection has some specific task. It would not protect
> you if an attacker is able to request the "welcome" page and parse it
> to extract the token. It would not protect you if you are using
> non-secured HTTP and an attacker is able to sniff network traffic.
>
> Best regards,
> Konstantin Kolinko
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>

Re: Which version of Tomcat supports Java 8

2015-09-24 Thread Violeta Georgieva

On Friday, 25 September 2015,  wrote:

> If I understood it correctly, Tomcat 7.0.x supports Java 6, 7 and 8.
> Correct?


Yes

Regards,
Violeta


>
>
> Thanks,
> Gloria
>
>
> -Original Message-
> From: André Warnier (tomcat) [mailto:a...@ice-sa.com ]
> Sent: Thursday, September 24, 2015 4:21 PM
> To: users@tomcat.apache.org 
> Subject: Re: Which version of Tomcat supports Java 8
>
> On 25.09.2015 01:03, gloria.zh...@wellsfargo.com  wrote:
> > Hi,
> >
> > We are currently using Tomcat 7.0.62. Does this version officially
> support Java 8? If not, which version of Tomcat supports it.
> >
>
> All you wish to know is here : http://tomcat.apache.org/whichversion.html
>
>
>
>
> -
> 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: WebEx meeting invitation: Apache Tomcat: TLS Virtual Hosting

2015-12-08 Thread Violeta Georgieva

Hi Mark,

2015-12-08 12:41 GMT+02:00 Mark Thomas :
>
> On 08/12/2015 10:19, gustavo.avitab...@unina.it wrote:
> > Hi Mark,
> >I tried to attend this meeting. I connected with WebEx,
> > I could see the slides, but I got no audio. The same
> > happened at you first meeting, a few days ago. I looked
> > at the first meeting you published in YouTube, with no
> > problems: the audio was there.
> >Can you suggest how can I attend the live meeting?
>
> The meetings are currently set up so you have to use a telephone to
> connect to the audio. You can either dial in or get the system to call
> you back.
>
> It looks like something did go wrong with the audio for this morning's
> meeting. As I said when I sent the first invitations out, this is new
> for us and we expect to have a few issues as we figure out how best to
> do this.
>
> For this evening's meeting I am going to try a couple of different things:
> 1. See if I can enable audio via the same device you are watching the
> video so you don;t need a separate phone line.
> 2. Dial in from a separate line and ensure that my audio feed is working.

I tried with dial in and with call back, but both were not working for me
this morning.

I was able to see the slides but there was no audio.

A colleague of mine also tried without success - no audio this morning.

For this evening's meeting I can join earlier and I also will be able to
tell you whether the audio is OK on my side.

Regards,
Violeta

> Mark
>
>
> >Thank you
> >Gustavo Avitabile
> >
> > Quoting Mark Thomas :
> >
> >>
> >> Hello,
> >>
> >> Mark Thomas invites you to join this WebEx meeting.
> >>
> >>
> >> Apache Tomcat: TLS Virtual Hosting
> >> Tuesday, 8 December 2015
> >> 10:00  |  GMT Time (London, GMT)  |  1 hr
> >>
> >>
> >> JOIN WEBEX MEETING
> >>
https://pivotal.webex.com/pivotal/j.php?MTID=md04c20b9c83695a23992a9a2f9ea1302
> >>
> >> Meeting number: 640 832 227
> >>
> >>
> >> JOIN BY PHONE
> >> Call-in toll-free number: 1-877-8818371  (US)
> >> Call-in number: 1-617-3374371  (US)
> >> Show global numbers:
> >> https://sites.google.com/a/pivotal.io/pivotal-it/pivotal-conferencing
> >> Attendee access code: 289 459 03
> >>
> >>
> >>
> >> Add this meeting to your calendar:
> >>
https://pivotal.webex.com/pivotal/j.php?MTID=m9e9c0d24e609886438948d2f4265823d
> >>
> >>
> >>
> >> Can't join the meeting? Contact support here:
> >> https://pivotal.webex.com/pivotal/mc
> >>
> >>
> >> IMPORTANT NOTICE: Please note that this WebEx service allows audio and
> >> other information sent during the session to be recorded, which may be
> >> discoverable in a legal matter. By joining this session, you
> >> automatically consent to such recordings. If you do not consent to
> >> being recorded, discuss your concerns with the host or do not join the
> >> session.
> >>
> >
> >
> >
> >
> > -
> > 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
>

[ANN] Apache Tomcat 7.0.67 released

2015-12-11 Thread Violeta Georgieva

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 7.0.67.

Apache Tomcat is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Expression Language and Java
WebSocket technologies.

This release contains a number of bug fixes and improvements compared to
version 7.0.65. The notable changes since 7.0.65 include:


- Allow file based configuration resources (e.g. key stores) to be
configured
  using URLs.

- Add an option to control (per context) quoting of EL expressions in JSP
  attributes. Restore the default behavior in Jasper to align with 7.0.64
and
  earlier as well as other JSP implementations.

- Add a new RestCsrfPreventionFilter that provides basic CSRF protection for
  REST APIs.

- Use instance manager for WebSocket server endpoint instances.

- Location headers for redirects now use relative URIs. This can be
controlled
  per Context with the useRelativeRedirects attribute.


Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-7.0-doc/changelog.html

Note: This version has 4 zip binaries: a generic one and
  three bundled with Tomcat native binaries for Windows operating
  systems running on different CPU architectures.

Note: Use of the Java WebSocket 1.1 implementation requires Java 7.

Note: If you use the APR/native AJP or HTTP connector you *must* upgrade
  to version 1.1.33 or later of the APR/native library.

Downloads:
http://tomcat.apache.org/download-70.cgi

Migration guides from Apache Tomcat 5.5.x and 6.0.x:
http://tomcat.apache.org/migration.html

Enjoy

The Apache Tomcat team

Re: CSRF errors after upgrade of tomcat 8

2015-12-14 Thread Violeta Georgieva

Hello,

2015-12-15 4:35 GMT+02:00 Baron Fujimoto :
>
> On Mon, Dec 14, 2015 at 09:12:20PM +, Mark Thomas wrote:
> >On 14/12/2015 20:49, Baron Fujimoto wrote:
> >> On Fri, Dec 11, 2015 at 05:02:43PM -1000, Baron Fujimoto wrote:
> >>> On Sat, Dec 12, 2015 at 12:16:01AM +, Mark Thomas wrote:
> >
> >
> >
> >>> I've confirmed that the problem begins with 8.0.29.
> >
> >Looking through the changelog it is hard to see how any of the changes
> >not in the Catalina section could trigger this. So, focussing on that
> >section...
> >
>  If you can find out how the CSRF protection is adding the token then
>  that will also help since it gives an idea of what to look for in the
>  changelog.
> >>>
> >>> I believe it's done using the OWASP CSRFGuard Project, and I have the
> >>> property files generated by the Grouper devs that define its
> >>> configuration. I'll query the Grouper folks to confirm and see if they
> >>> can provide a relevant and succinct explanation about this in
particular.
> >>
> >> The Grouper devs explain, "Javascript sets an HTTP header called
> >> OWASP_CSRFTOKEN: on requests (some excluded per properties file)".
> >
> >That doesn't explain how/where the token is generated or what component
> >validates it server side. I'm guessing a Filter does the validation.
> >
> >> Per the properties file, I believe the following are excluded:
> >>
> >> org.owasp.csrfguard.unprotected.Default=%servletContext%/
> >
> >Hmm. This first one combined with the last entry in the Catalina section
> >of the 8.0.29 changelog look like a possibility.
> >
> >Try each of the following (one at a time, not together) to see if they
> >fix it:
>
> Neither of these, tried independently, appeared to have any effect.
>
> >a) Add the following (note the lack of trailing slash) to the properties
> >file:
> >
> >org.owasp.csrfguard.unprotected.Upload=%servletContext%
>
> I tried this as described, but since I wasn't sure if you really meant the
> .Default property I also tried that, just in case (separate tests,
> performed independently). I tried both by adding the suggested definitions
> after their original definitions (in case they superceded them) and by
> replacing the original definitions.
>
>
> >b) Set mapperContextRootRedirectEnabled="true" and
> >mapperDirectoryRedirectEnabled="true" on the Context in
> >$CATALINA_BASE/conf/context.xml
>
> The resulting $CATALINA_BASE/conf/context.xml was:
>
> 
> WEB-INF/web.xml
> ${catalina.base}/conf/web.xml
>
> mapperContextRootRedirectEnabled="true"
> mapperDirectoryRedirectEnabled="true"
> 

mapperContextRootRedirectEnabled and
mapperDirectoryRedirectEnabled

are attributes of the Context so your context.xml should look like the one
below:


WEB-INF/web.xml
${catalina.base}/conf/web.xml


Regards,
Violeta

> Aloha,
> -baron
>
> >> org.owasp.csrfguard.unprotected.Upload=%servletContext%/upload.html
> >>
org.owasp.csrfguard.unprotected.JavaScriptServlet=%servletContext%/JavaScriptServlet
> >> org.owasp.csrfguard.unprotected.Ajax=%servletContext%/ajax.html
> >> org.owasp.csrfguard.unprotected.Error=%servletContext%/error.html
> >> org.owasp.csrfguard.unprotected.Index=%servletContext%/index.html
> >>
org.owasp.csrfguard.unprotected.JavaScript=%servletContext%/javascript.html
> >> org.owasp.csrfguard.unprotected.Tag=%servletContext%/tag.jsp
> >> org.owasp.csrfguard.unprotected.Redirect=%servletContext%/redirect.jsp
> >> org.owasp.csrfguard.unprotected.Forward=%servletContext%/forward.jsp
> >> org.owasp.csrfguard.unprotected.Session=%servletContext%/session.jsp
> >>
> >> CSRFGuard defines the following actions for a detected attack:
> >>
> >> org.owasp.csrfguard.action.Log=org.owasp.csrfguard.action.Log
> >> org.owasp.csrfguard.action.Log.Message=potential cross-site request
forgery (CSRF) attack thwarted (user:%user%, ip:%remote_ip%,
method:%request_method%, uri:%request_uri%, error:%exception_message%)
> >> org.owasp.csrfguard.action.Redirect=org.owasp.csrfguard.action.Redirect
> >> org.owasp.csrfguard.action.Redirect.Page=%servletContext%/error.html
> >> org.owasp.csrfguard.action.Rotate=org.owasp.csrfguard.action.Rotate
> >>
> >> Other misc CSRFGuard confs:
> >>
> >> org.owasp.csrfguard.TokenName=OWASP_CSRFTOKEN
> >> org.owasp.csrfguard.SessionKey=OWASP_CSRFTOKEN
> >> org.owasp.csrfguard.TokenLength=32
> >> org.owasp.csrfguard.PRNG=SHA1PRNG
> >> org.owasp.csrfguard.PRNG.Provider=SUN
> >>
> >> org.owasp.csrfguard.JavascriptServlet.domainStrict = true
> >> org.owasp.csrfguard.JavascriptServlet.cacheControl = private,
maxage=28800
> >> org.owasp.csrfguard.JavascriptServlet.refererPattern = .*
> >> org.owasp.csrfguard.JavascriptServlet.refererMatchDomain = true
> >> org.owasp.csrfguard.JavascriptServlet.injectIntoForms = true
> >> org.owasp.csrfguard.JavascriptServlet.injectIntoAttributes = true
> >>
> >> Here is an example of a resulting URL/token that results in the error.
> >>
> >> <

Re: [ANN] Apache Tomcat 8.0.29 available

2015-11-25 Thread Violeta Georgieva

2015-11-25 21:38 GMT+02:00 Felix Schumacher <
felix.schumac...@internetallee.de>:
>
>
>
> Am 25. November 2015 20:24:17 MEZ, schrieb Violeta Georgieva <
miles...@gmail.com>:
> >Hi,
> >
> >2015-11-25 20:42 GMT+02:00 David Balažic <david.bala...@comtrade.com>:
> >>
> >> Typo on http://tomcat.apache.org/tomcat-8.0-doc/changelog.html
> >>
> >> "TLSv1.0 is no an alias"
> >>
> >> Should probably be "TLSv1.0 is not an alias"
> >
> >I fixed it.
>
> I believe it should have been "TLSv1.0 is no(w) an alias ... and will
no(t) work ..."

Yep you are right.
I fixed it.

> Regards,
> Felix
>
> >Thanks,
> >Violeta
> >
> >> Regards,
> >> David Balažic
> >>
> >> > -Original Message-
> >> > From: Mark Thomas [mailto:ma...@apache.org]
> >> > Sent: 25. November 2015 17:22
> >> > To: users@tomcat.apache.org
> >> > Cc: d...@tomcat.apache.org; annou...@apache.org;
> >> > annou...@tomcat.apache.org
> >> > Subject: [ANN] Apache Tomcat 8.0.29 available
> >> > Importance: Low
> >> >
> >> > The Apache Tomcat team announces the immediate availability of
> >Apache
> >> > Tomcat 8.0.29.
> >> >
> >> > Apache Tomcat 8 is an open source software implementation of the
> >Java
> >> > Servlet, JavaServer Pages, Java Unified Expression Language and
> >Java
> >> > WebSocket technologies.
> >> >
> >> > Apache Tomcat 8.0.29 includes fixes for issues identified in 8.0.28
> >as
> >> > well as other enhancements and changes. The notable changes since
> >8.0.28
> >> > include:
> >> >
> >> > - Add an option to control (per context) quoting of EL expressions
> >in
> >> >   JSP attributes
> >> >
> >> > - Correct a regression in the fix for 56777 that added support for
> >> >   URIs in config file locations
> >> >
> >> > - Add a new RestCsrfPreventionFilter that provides basic CSRF
> >> >   protection for REST APIs
> >> >
> >> > -  Use instance manager for WebSocket server endpoint instances
> >> >
> >> >
> >> > Please refer to the change log for the complete list of changes:
> >> > http://tomcat.apache.org/tomcat-8.0-doc/changelog.html
> >> >
> >> > Downloads:
> >> > http://tomcat.apache.org/download-80.cgi
> >> >
> >> > Migration guides from Apache Tomcat 5.5.x, 6.0.x and 7.0.x:
> >> > http://tomcat.apache.org/migration.html
> >> >
> >> > Enjoy!
> >> >
> >> > - The Apache Tomcat team
> >> >
> >> >
> >-
> >> > 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: [ANN] Apache Tomcat 8.0.29 available

2015-11-25 Thread Violeta Georgieva

Hi,

2015-11-25 20:42 GMT+02:00 David Balažic :
>
> Typo on http://tomcat.apache.org/tomcat-8.0-doc/changelog.html
>
> "TLSv1.0 is no an alias"
>
> Should probably be "TLSv1.0 is not an alias"

I fixed it.
Thanks,
Violeta

> Regards,
> David Balažic
>
> > -Original Message-
> > From: Mark Thomas [mailto:ma...@apache.org]
> > Sent: 25. November 2015 17:22
> > To: users@tomcat.apache.org
> > Cc: d...@tomcat.apache.org; annou...@apache.org;
> > annou...@tomcat.apache.org
> > Subject: [ANN] Apache Tomcat 8.0.29 available
> > Importance: Low
> >
> > The Apache Tomcat team announces the immediate availability of Apache
> > Tomcat 8.0.29.
> >
> > Apache Tomcat 8 is an open source software implementation of the Java
> > Servlet, JavaServer Pages, Java Unified Expression Language and Java
> > WebSocket technologies.
> >
> > Apache Tomcat 8.0.29 includes fixes for issues identified in 8.0.28 as
> > well as other enhancements and changes. The notable changes since 8.0.28
> > include:
> >
> > - Add an option to control (per context) quoting of EL expressions in
> >   JSP attributes
> >
> > - Correct a regression in the fix for 56777 that added support for
> >   URIs in config file locations
> >
> > - Add a new RestCsrfPreventionFilter that provides basic CSRF
> >   protection for REST APIs
> >
> > -  Use instance manager for WebSocket server endpoint instances
> >
> >
> > Please refer to the change log for the complete list of changes:
> > http://tomcat.apache.org/tomcat-8.0-doc/changelog.html
> >
> > Downloads:
> > http://tomcat.apache.org/download-80.cgi
> >
> > Migration guides from Apache Tomcat 5.5.x, 6.0.x and 7.0.x:
> > http://tomcat.apache.org/migration.html
> >
> > Enjoy!
> >
> > - The Apache Tomcat team
> >
> > -
> > 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: [ANN] Apache Tomcat 8.0.29 available

2015-11-25 Thread Violeta Georgieva

Chris,

2015-11-26 2:52 GMT+02:00 Christopher Schultz <ch...@christopherschultz.net
>:
>
> Violeta,
>
> On 11/25/15 3:00 PM, Violeta Georgieva wrote:
> > 2015-11-25 21:38 GMT+02:00 Felix Schumacher <
> > felix.schumac...@internetallee.de>:
> >>
> >>
> >>
> >> Am 25. November 2015 20:24:17 MEZ, schrieb Violeta Georgieva <
> > miles...@gmail.com>:
> >>> Hi,
> >>>
> >>> 2015-11-25 20:42 GMT+02:00 David Balažic <david.bala...@comtrade.com>:
> >>>>
> >>>> Typo on http://tomcat.apache.org/tomcat-8.0-doc/changelog.html
> >>>>
> >>>> "TLSv1.0 is no an alias"
> >>>>
> >>>> Should probably be "TLSv1.0 is not an alias"
> >>>
> >>> I fixed it.
> >>
> >> I believe it should have been "TLSv1.0 is no(w) an alias ... and will
> > no(t) work ..."
> >
> > Yep you are right.
> > I fixed it.
>
> Also, I'm fairly sure:
>
> > Synchronize OpenSSL to JSSE cipher mapping to recent OpenSSL
> > changes. In particular, TLSv1.0 is no an alias for those ciphers that
> > require TLSv1 and will no work with SDSLv3.
>
> s/SDSLv3/SSLv3/

I fixed that with the first commit. Do I miss something?

Thanks,
Vily

> -chris
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>

Re: Tomcat's JNDI lookups fail if java.naming.factory.object property is specified

2015-11-19 Thread Violeta Georgieva

Hi,

2015-11-16 8:39 GMT+02:00 Dimitar Valov :
>
> Hello,
>
> It is really easy to reproduce this problem even if the default factory
> org.apache.naming.factory.ResourceFactory is used (set
> JAVA_OPTS=%JAVA_OPTS% -Djava.naming.factory.object=
> org.apache.naming.factory.ResourceFactory)
>
> Do you think that this should happen?

I found this in the archives [1]

Regards,
Violeta

[1] http://markmail.org/message/ux4tbigxqrm3tmzy

> Best Regards,
> Dimitar
>
> On Thu, Nov 5, 2015 at 1:51 PM, Dimitar Valov 
> wrote:
>
> > Hello,
> >
> > Exceptions such as this are found in the logs when
> > java.naming.factory.object is present
> > 04-Nov-2015 15:40:51.560 SEVERE [main]
> > org.apache.catalina.realm.UserDatabaseRealm.startInternal Exception
looking
> > up UserDatabase under key UserDatabase
> >  java.lang.ClassCastException: Cannot cast class
> > org.apache.naming.ResourceRef to interface
org.apache.catalina.UserDatabase
> > at
> >
org.apache.catalina.realm.UserDatabaseRealm.startInternal(UserDatabaseRealm.java:232)
> > at
> > org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
> > at
> >
org.apache.catalina.realm.CombinedRealm.startInternal(CombinedRealm.java:249)
> > at
> >
org.apache.catalina.realm.LockOutRealm.startInternal(LockOutRealm.java:120)
> > at
> > org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
> > at
> >
org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:905)
> > at
> >
org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:262)
> > at
> > org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
> > at
> >
org.apache.catalina.core.StandardService.startInternal(StandardService.java:439)
> > at
> > org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
> > at
> >
org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:769)
> > at
> > org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
> > at org.apache.catalina.startup.Catalina.start(Catalina.java:625)
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > at
> >
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> > at
> >
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > at java.lang.reflect.Method.invoke(Method.java:497)
> > at
org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:351)
> > at
org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:485)
> > It is also not possible to add additional ObjectFactories with
> > java.naming.factory.object property.
> >
> > Steps to reproduce:
> >
> > setenv.bat:
> > set JAVA_OPTS=%JAVA_OPTS%
> >
-Djava.naming.factory.object=org.apache.naming.factory.ResourceFactory:custom.CustomObjectFactory
> >
> > setenv.sh:
> > export JAVA_OPTS=$JAVA_OPTS
> >
-Djava.naming.factory.object=org.apache.naming.factory.ResourceFactory:custom.CustomObjectFactory
> >
> > Details:
> >
> > 1. org.apache.naming.ResourceRef.getFactoryClassName() returns null:
> >
https://github.com/apache/tomcat/blob/trunk/java/org/apache/naming/ResourceRef.java#L134
> >
> > 2. Consequently
> >
http://docs.oracle.com/javase/8/docs/api/javax/naming/spi/NamingManager.html#getObjectInstance-java.lang.Object-javax.naming.Name-javax.naming.Context-java.util.Hashtable-
falls
> > to option 3, however the environment does not contain any values and
> > returns the refInfo (An object created using refInfo; or refInfo if an
> > object cannot be created using the algorithm described above.).
> >
> > Possible Reasons:
> >
> > 1. org.apache.catalina.core.NamingContextListener.lifecycleEvent() uses
an
> > empty Hashtable for specifying the environment of the NamingContext:
> >
https://github.com/apache/tomcat/blob/trunk/java/org/apache/catalina/core/NamingContextListener.java#L235
> >This is the place where the environment is initially created before
> > lookups are made.
> >
> > Possible Solutions:
> >
> > 1. Add the object factories as specified in the environment to the
initial
> > context environment:
> >
> >contextEnv.put(javax.naming.Context.OBJECT_FACTORIES,
> > System.getProperty(javax.naming.Context.OBJECT_FACTORIES));
> >
> >in
> >
https://github.com/apache/tomcat/blob/trunk/java/org/apache/catalina/core/NamingContextListener.java#L235
> >
> > Attachments:
> >
> > The projects.zip contains two maven projects: a web application that
uses
> > custom resource type and extension to Tomcat that adds a custom
> > ObjectFactory.
> >
> > Also regarding
> >
https://tomcat.apache.org/tomcat-8.0-doc/jndi-resources-howto.html#Adding_Custom_Resource_Factories
,
> > there is step "2. Declare Your Resource Requirements" which states to
add a
> > resource-env-ref inside web.xml. I've noticed when the resource is
> >

1 2 3 >

1 - 100 of 210 matches

Mail list logo