AW: Java6 JAX-WS and Tomcat interoperability
Internal / external, it's just a matter of preference and what works for your app. The internal (i.e. bundled with the JVM) classes are more convenient to use, but you have no choice as to the version you get. With external JARs you can use a specific version, often more recent than what is bundled with the JVM. Thanks a lot for your opinion. I assumed this answer. I think we will rollback to the external package. with kind regards Michael - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 7 / Java 7 with TLS 1.2 algorithms
Tomcat 7.0.40 seems to work well with TLS 1.2, forced by using a sslEnabledProtocols=TLSv1.2 attribute on the Connector. But I haven't been able to make it work with any of the SHA256/384 algorithms - they always show up in the Ignoring unsupported cipher suite list. I get the same thing happening when I try to use them from client code, so I know it's not a Tomcat issue, but I'm hoping someone knows a workaround. Any suggestions? Thanks, - Dennis - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Request for admittance to ContributorsGroup
Hi, near four years ago I've inserted Open Gate in http://wiki.apache.org/tomcat/SupportAndTraining I would like to update some information ( years of activity, links to logo, may be a special page on our web site dedicated to Tomcat ). Could someone admit me to ContributorsGroup ? My wiki user is LucaVisconti. Best regards. -- -- *Luca Visconti* * Amministratore* Open Gate S.r.l. ( build 2.0 ) Via G. Di Vittorio, 7 - 20063 - Cernusco Sul Naviglio (MI) - ITALY http://www.opengate.biz
How to forward subdomain to a destination URL using Domain registrar Cpanel?
Hi, I have purchased a domain xyz.com but no hosting. Can I forward a subdomain say photo.xyz.com to my flickr account having URL like flickr.com/photos/abcadjsakjda. Thanks, Norah Jones - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Having trouble with common.loader
On Aug 21, 2013, at 5:09 PM, D C dc12...@gmail.com wrote:
I added verbose, it does not appear to attempt to load anything from
/web/lib/
Ok. Where do you see it loading classes from? /WEB-INF/lib/*.jar? Do you see
any classes listed that you would expect to be loaded from /web/lib? Where are
they being loaded from?
for permissions i verified that i could read the files as the tomcat user.
Good
Thanks,
Dan
On Wed, Aug 21, 2013 at 5:01 PM, Daniel Mikusa dmik...@gopivotal.comwrote:
On Aug 21, 2013, at 4:48 PM, D C dc12...@gmail.com wrote:
So here is what I'm trying to achieve.
1. The tomcat install remains clean. I want to be able to change the
tomcat installation without messing with the app.
2. We want our applications to be decoupled from the libraries which it
needs. ( i understand the pains you are referring to.. this was a bit
of
debate, but this is what we want to do).
3. We want our engineering team to manage libs via RPM, not the
developers.
tomcat is installed like so via RPM.
/opt/tomcat-6.0.35
/opt/tomcat-7.0.39
/opt/tomcat-7.0.40
/tomcat symlinks to which ever /opt/tomcat-7.0.40
Context entries go in /tomcat/conf/Catalina/localhost/myApp.xml
/web/webapps - holds our webapps. This much works perfectly.
/web/conf/myApp - holds our application configs.
/web/lib - holds any libs that are not part of the base tomcat
installation. This is managed by rpm.
If unpack a war file, and it has contents inside WEB_INF/lib, we will
consider that a broken build.
Everything works, except that my libs are not loading.. I had thought
that
I could add /web/lib,/web/lib/*.jar to the common.loader. Am I mistaken
by
this?
You can certainly add entries to common.loader and yours looks OK.
Assuming the paths exist and permissions on those paths are correct, I'd
suggest adding the -verbose JVM argument to your bin/setenv.sh file.
This will show you the location of classes that are being loaded. Perhaps
it is loading classes from those locations and there is some other reason
you are getting the ClassNotFoundException.
Dan
Thanks,
Dan
On Wed, Aug 21, 2013 at 4:27 PM, Daniel Mikusa dmik...@gopivotal.com
wrote:
On Aug 21, 2013, at 4:09 PM, David kerber dcker...@verizon.net wrote:
Basically you're trying to defeat the way the system is designed to
work. Don't do that…
+1 Don't do what you've described unless you have a very good reason.
It
will cause you many headaches.
Keep all of your JAR files in WEB-INF/lib, with the exception of JDBC
drivers. Put those in $CATALINA_BASE/lib.
Dan
On 8/21/2013 3:58 PM, D C wrote:
Tomcat 7.0.40
CentOS 6.3
Java 1.7.0_21
I am trying to move all libraries out of my webapps directory, and
into
a
common place.
I have my libs that were bundled with tomcat in /tomcat/lib (the
default),
and my extra libs i want to keep in /web/lib.
I've updated /tomcat/conf/catalina.properties to use the following:
common.loader=${catalina.base}/lib,${catalina.base}/lib/*.jar,/web/lib,/web/lib/*.jar
I have my database resource located in
/tomcat/conf/Catalina/localhost/myApp.xml (probably not relevant)
When I start tomcat, I get the errors listed below. However if I move
/web/lib/* to webapps/myApp/WEB_INF/lib/ it works fine.
What am I missing here?
catalina.out snip.
SEVERE: ContainerBase.addChild: start:
org.apache.catalina.LifecycleException: Failed to start component
[StandardEngine[Catalina].StandardHost[localhost].StandardContext[/myApp]]
at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:154)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901)
at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877)
at
org.apache.catalina.core.StandardHost.addChild(StandardHost.java:633)
at
org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:657)
at
org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1636)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.NoClassDefFoundError:
org/springframework/core/io/Resource
at java.lang.Class.getDeclaredFields0(Native Method)
at java.lang.Class.privateGetDeclaredFields(Class.java:2317)
at java.lang.Class.getDeclaredFields(Class.java:1762)
at
org.apache.catalina.util.Introspection.getDeclaredFields(Introspection.java:106)
at
Re: How to forward subdomain to a destination URL using Domain registrar Cpanel?
Norah Jones wrote: Hi, I have purchased a domain xyz.com but no hosting. Can I forward a subdomain say photo.xyz.com to my flickr account having URL like flickr.com/photos/abcadjsakjda. http://www.youtube.com/watch?v=cxFYwNLv67s This is, like, the Tomcat Users support list ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7 / Java 7 with TLS 1.2 algorithms
Hello I suppose you need to run your JVM with the unrestricted policy files (on b= oth client and server sides). You have to download them from Oracle website= for your java version, and replace the old. These files are : local_policy.jar US_export_policy.jar Regards 2013/8/22 d...@sosnoski.com: Tomcat 7.0.40 seems to work well with TLS 1.2, forced by using a sslEnabledProtocols=TLSv1.2 attribute on the Connector. But I haven't been able to make it work with any of the SHA256/384 algorithms - they always show up in the Ignoring unsupported cipher suite list. I get the same thing happening when I try to use them from client code, so I know it's not a Tomcat issue, but I'm hoping someone knows a workaround. Any suggestions? Thanks, - Dennis - 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
manager quick guide
Hey: I am trying to understand how the manager works, so I just want to implement it simply with a blank tomcat and the sample.war. I am finding the documentation to be unclear, although it is probably my lack of experience that is tripping me up. Can anyone tell me what steps are required to allow the manager to work with a simple app installed at localhost:1919:/sample? I would greatly appreciate any pointers here! Thanks, Captain Vick - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 7 / Java 7 with TLS 1.2 algorithms
what's supposed to happen: The specified cipher in SSLCipherSuiteSSLCipherSuite is supposed to be enabled when specified within SSLCipherSuiteSSLCipherSuite=SHA256/384 to allow the Server to arbitrate the ordering of ciphers(instead of the client) SSLHonorCipherOrder=true http://tomcat.apache.org/tomcat-7.0-doc/config/http.html does this not work for you? Martin Gainty __ Please do not alter or disrupt this transmission..Thank You From: d...@sosnoski.com Subject: Tomcat 7 / Java 7 with TLS 1.2 algorithms To: users@tomcat.apache.org CC: Date: Thu, 22 Aug 2013 04:41:54 -0400 Tomcat 7.0.40 seems to work well with TLS 1.2, forced by using a sslEnabledProtocols=TLSv1.2 attribute on the Connector. But I haven't been able to make it work with any of the SHA256/384 algorithms - they always show up in the Ignoring unsupported cipher suite list. I get the same thing happening when I try to use them from client code, so I know it's not a Tomcat issue, but I'm hoping someone knows a workaround. Any suggestions? Thanks, - Dennis - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Having trouble with common.loader
[tomcat@test05 logs]# grep from file catalina.out | sed 's/.*from
file//g' | sed 's/\/lib\/.*/\/lib/g' | sort -u
:/opt/apache-tomcat-7.0.40/bin/bootstrap.jar]
:/opt/apache-tomcat-7.0.40/bin/tomcat-juli.jar]
:/opt/apache-tomcat-7.0.40/lib
:/opt/jdk1.7.0.21/jre/lib
:/web/webapps/myApp/WEB-INF/classes/com/myco/management/spring_utils/ContextLoaderListener.class]
:/web/webapps/myApp/WEB-INF/lib
Thanks,
Dan
On Thu, Aug 22, 2013 at 6:47 AM, Daniel Mikusa dmik...@gopivotal.comwrote:
On Aug 21, 2013, at 5:09 PM, D C dc12...@gmail.com wrote:
I added verbose, it does not appear to attempt to load anything from
/web/lib/
Ok. Where do you see it loading classes from? /WEB-INF/lib/*.jar? Do
you see any classes listed that you would expect to be loaded from
/web/lib? Where are they being loaded from?
for permissions i verified that i could read the files as the tomcat
user.
Good
Thanks,
Dan
On Wed, Aug 21, 2013 at 5:01 PM, Daniel Mikusa dmik...@gopivotal.com
wrote:
On Aug 21, 2013, at 4:48 PM, D C dc12...@gmail.com wrote:
So here is what I'm trying to achieve.
1. The tomcat install remains clean. I want to be able to change the
tomcat installation without messing with the app.
2. We want our applications to be decoupled from the libraries which it
needs. ( i understand the pains you are referring to.. this was a bit
of
debate, but this is what we want to do).
3. We want our engineering team to manage libs via RPM, not the
developers.
tomcat is installed like so via RPM.
/opt/tomcat-6.0.35
/opt/tomcat-7.0.39
/opt/tomcat-7.0.40
/tomcat symlinks to which ever /opt/tomcat-7.0.40
Context entries go in /tomcat/conf/Catalina/localhost/myApp.xml
/web/webapps - holds our webapps. This much works perfectly.
/web/conf/myApp - holds our application configs.
/web/lib - holds any libs that are not part of the base tomcat
installation. This is managed by rpm.
If unpack a war file, and it has contents inside WEB_INF/lib, we will
consider that a broken build.
Everything works, except that my libs are not loading.. I had thought
that
I could add /web/lib,/web/lib/*.jar to the common.loader. Am I
mistaken
by
this?
You can certainly add entries to common.loader and yours looks OK.
Assuming the paths exist and permissions on those paths are correct, I'd
suggest adding the -verbose JVM argument to your bin/setenv.sh file.
This will show you the location of classes that are being loaded.
Perhaps
it is loading classes from those locations and there is some other
reason
you are getting the ClassNotFoundException.
Dan
Thanks,
Dan
On Wed, Aug 21, 2013 at 4:27 PM, Daniel Mikusa dmik...@gopivotal.com
wrote:
On Aug 21, 2013, at 4:09 PM, David kerber dcker...@verizon.net
wrote:
Basically you're trying to defeat the way the system is designed to
work. Don't do that…
+1 Don't do what you've described unless you have a very good reason.
It
will cause you many headaches.
Keep all of your JAR files in WEB-INF/lib, with the exception of
JDBC
drivers. Put those in $CATALINA_BASE/lib.
Dan
On 8/21/2013 3:58 PM, D C wrote:
Tomcat 7.0.40
CentOS 6.3
Java 1.7.0_21
I am trying to move all libraries out of my webapps directory, and
into
a
common place.
I have my libs that were bundled with tomcat in /tomcat/lib (the
default),
and my extra libs i want to keep in /web/lib.
I've updated /tomcat/conf/catalina.properties to use the following:
common.loader=${catalina.base}/lib,${catalina.base}/lib/*.jar,/web/lib,/web/lib/*.jar
I have my database resource located in
/tomcat/conf/Catalina/localhost/myApp.xml (probably not relevant)
When I start tomcat, I get the errors listed below. However if I
move
/web/lib/* to webapps/myApp/WEB_INF/lib/ it works fine.
What am I missing here?
catalina.out snip.
SEVERE: ContainerBase.addChild: start:
org.apache.catalina.LifecycleException: Failed to start component
[StandardEngine[Catalina].StandardHost[localhost].StandardContext[/myApp]]
at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:154)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901)
at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877)
at
org.apache.catalina.core.StandardHost.addChild(StandardHost.java:633)
at
org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:657)
at
org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1636)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
Migrating from GlassFish to Tomcat 7
I have a GWT application which currently is running on GlassFish 3.x. I want to migrate to Tomcat 7. Previously, I would store properties that the GWT application could retrieve by org.apache.commons.configuration.SystemConfiguration. I would put these settings in my domain.xml for GlassFish. What is the Tomcat equivalent? I tried putting settings under my WEB-INF\web.xml file as context-paramsection. However, my GWT application cannot see them still. Where should I put settings that can be read by calling org.apache.commons.configuration.SystemConfiguration from my GWT app from Tomcat?
Re: Tomcat 7 / Java 7 with TLS 1.2 algorithms
I've already done that, though as far as I can see that doesn't effect the digest algorithms (only the encryption options). - Dennis On 08/23/2013 12:24 AM, Aurélien Terrestris wrote: Hello I suppose you need to run your JVM with the unrestricted policy files (on b= oth client and server sides). You have to download them from Oracle website= for your java version, and replace the old. These files are : local_policy.jar US_export_policy.jar Regards 2013/8/22 d...@sosnoski.com: Tomcat 7.0.40 seems to work well with TLS 1.2, forced by using a sslEnabledProtocols=TLSv1.2 attribute on the Connector. But I haven't been able to make it work with any of the SHA256/384 algorithms - they always show up in the Ignoring unsupported cipher suite list. I get the same thing happening when I try to use them from client code, so I know it's not a Tomcat issue, but I'm hoping someone knows a workaround. Any suggestions? Thanks, - Dennis - 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: Having trouble with common.loader
On Aug 22, 2013, at 8:38 AM, D C dc12...@gmail.com wrote:
[tomcat@test05 logs]# grep from file catalina.out | sed 's/.*from
file//g' | sed 's/\/lib\/.*/\/lib/g' | sort -u
:/opt/apache-tomcat-7.0.40/bin/bootstrap.jar]
:/opt/apache-tomcat-7.0.40/bin/tomcat-juli.jar]
:/opt/apache-tomcat-7.0.40/lib
:/opt/jdk1.7.0.21/jre/lib
:/web/webapps/myApp/WEB-INF/classes/com/myco/management/spring_utils/ContextLoaderListener.class]
:/web/webapps/myApp/WEB-INF/lib
Can you show the unaltered output? If you want to filter out stuff to make it
smaller, filter out any classes that were loaded from the JDK.
Dan
Thanks,
Dan
On Thu, Aug 22, 2013 at 6:47 AM, Daniel Mikusa dmik...@gopivotal.comwrote:
On Aug 21, 2013, at 5:09 PM, D C dc12...@gmail.com wrote:
I added verbose, it does not appear to attempt to load anything from
/web/lib/
Ok. Where do you see it loading classes from? /WEB-INF/lib/*.jar? Do
you see any classes listed that you would expect to be loaded from
/web/lib? Where are they being loaded from?
for permissions i verified that i could read the files as the tomcat
user.
Good
Thanks,
Dan
On Wed, Aug 21, 2013 at 5:01 PM, Daniel Mikusa dmik...@gopivotal.com
wrote:
On Aug 21, 2013, at 4:48 PM, D C dc12...@gmail.com wrote:
So here is what I'm trying to achieve.
1. The tomcat install remains clean. I want to be able to change the
tomcat installation without messing with the app.
2. We want our applications to be decoupled from the libraries which it
needs. ( i understand the pains you are referring to.. this was a bit
of
debate, but this is what we want to do).
3. We want our engineering team to manage libs via RPM, not the
developers.
tomcat is installed like so via RPM.
/opt/tomcat-6.0.35
/opt/tomcat-7.0.39
/opt/tomcat-7.0.40
/tomcat symlinks to which ever /opt/tomcat-7.0.40
Context entries go in /tomcat/conf/Catalina/localhost/myApp.xml
/web/webapps - holds our webapps. This much works perfectly.
/web/conf/myApp - holds our application configs.
/web/lib - holds any libs that are not part of the base tomcat
installation. This is managed by rpm.
If unpack a war file, and it has contents inside WEB_INF/lib, we will
consider that a broken build.
Everything works, except that my libs are not loading.. I had thought
that
I could add /web/lib,/web/lib/*.jar to the common.loader. Am I
mistaken
by
this?
You can certainly add entries to common.loader and yours looks OK.
Assuming the paths exist and permissions on those paths are correct, I'd
suggest adding the -verbose JVM argument to your bin/setenv.sh file.
This will show you the location of classes that are being loaded.
Perhaps
it is loading classes from those locations and there is some other
reason
you are getting the ClassNotFoundException.
Dan
Thanks,
Dan
On Wed, Aug 21, 2013 at 4:27 PM, Daniel Mikusa dmik...@gopivotal.com
wrote:
On Aug 21, 2013, at 4:09 PM, David kerber dcker...@verizon.net
wrote:
Basically you're trying to defeat the way the system is designed to
work. Don't do that…
+1 Don't do what you've described unless you have a very good reason.
It
will cause you many headaches.
Keep all of your JAR files in WEB-INF/lib, with the exception of
JDBC
drivers. Put those in $CATALINA_BASE/lib.
Dan
On 8/21/2013 3:58 PM, D C wrote:
Tomcat 7.0.40
CentOS 6.3
Java 1.7.0_21
I am trying to move all libraries out of my webapps directory, and
into
a
common place.
I have my libs that were bundled with tomcat in /tomcat/lib (the
default),
and my extra libs i want to keep in /web/lib.
I've updated /tomcat/conf/catalina.properties to use the following:
common.loader=${catalina.base}/lib,${catalina.base}/lib/*.jar,/web/lib,/web/lib/*.jar
I have my database resource located in
/tomcat/conf/Catalina/localhost/myApp.xml (probably not relevant)
When I start tomcat, I get the errors listed below. However if I
move
/web/lib/* to webapps/myApp/WEB_INF/lib/ it works fine.
What am I missing here?
catalina.out snip.
SEVERE: ContainerBase.addChild: start:
org.apache.catalina.LifecycleException: Failed to start component
[StandardEngine[Catalina].StandardHost[localhost].StandardContext[/myApp]]
at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:154)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901)
at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877)
at
org.apache.catalina.core.StandardHost.addChild(StandardHost.java:633)
at
org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:657)
at
org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1636)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at
Re: Migrating from GlassFish to Tomcat 7
On Aug 22, 2013, at 8:48 AM, B W bw20130...@gmail.com wrote: I have a GWT application which currently is running on GlassFish 3.x. I want to migrate to Tomcat 7. Previously, I would store properties that the GWT application could retrieve by org.apache.commons.configuration.SystemConfiguration. Looks like this class is loading items from system properties. I would put these settings in my domain.xml for GlassFish. What is the Tomcat equivalent? I tried putting settings under my WEB-INF\web.xml file as context-paramsection. However, my GWT application cannot see them still. Where should I put settings that can be read by calling org.apache.commons.configuration.SystemConfiguration from my GWT app from Tomcat? Based on that, you'd want to add system properties in $CATALINA_BASE/bin/setenv.sh. Note this file doesn't exist by default, you'll need to create it. Ex: CATALINA_OPTs=-Dmy.property.1=xyz -Dmy.property.2=abc Dan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat connectors and NTFS permission
HI, Tomcat connectors don't seem to honor the NTFS permissions set for the files. Is there a way to achieve this ? Thanks, Asha
Re: Request for admittance to ContributorsGroup
2013/8/22 Luca Visconti l.visco...@opengate.biz: Hi, near four years ago I've inserted Open Gate in http://wiki.apache.org/tomcat/SupportAndTraining I would like to update some information ( years of activity, links to logo, may be a special page on our web site dedicated to Tomcat ). Could someone admit me to ContributorsGroup ? My wiki user is LucaVisconti. Done. 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 7 / Java 7 with TLS 1.2 algorithms
According to RFC 5246 Appendix C (TLS 1.2), there is no SHA384. See : http://www.ietf.org/rfc/rfc5246.txt The JSSE Reference Guide also doesn't talk about this SHA384 as an implementation requirement. See : http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#impl This means you have a problem with SHA256 only. Maybe it's easier to test on client-side, with one of the following ciphers (that you find on the same Reference Guide ) for example : TLS_DH_RSA_WITH_AES_256_CBC_SHA256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 Let me know if this works, or I will try to test by myself with my own client. 2013/8/22 Dennis Sosnoski d...@sosnoski.com: I've already done that, though as far as I can see that doesn't effect the digest algorithms (only the encryption options). - Dennis On 08/23/2013 12:24 AM, Aurélien Terrestris wrote: Hello I suppose you need to run your JVM with the unrestricted policy files (on b= oth client and server sides). You have to download them from Oracle website= for your java version, and replace the old. These files are : local_policy.jar US_export_policy.jar Regards 2013/8/22 d...@sosnoski.com: Tomcat 7.0.40 seems to work well with TLS 1.2, forced by using a sslEnabledProtocols=TLSv1.2 attribute on the Connector. But I haven't been able to make it work with any of the SHA256/384 algorithms - they always show up in the Ignoring unsupported cipher suite list. I get the same thing happening when I try to use them from client code, so I know it's not a Tomcat issue, but I'm hoping someone knows a workaround. Any suggestions? Thanks, - Dennis - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Migrating from GlassFish to Tomcat 7
Thank you - it's working! On Thu, Aug 22, 2013 at 9:04 AM, Daniel Mikusa dmik...@gopivotal.comwrote: On Aug 22, 2013, at 8:48 AM, B W bw20130...@gmail.com wrote: I have a GWT application which currently is running on GlassFish 3.x. I want to migrate to Tomcat 7. Previously, I would store properties that the GWT application could retrieve by org.apache.commons.configuration.SystemConfiguration. Looks like this class is loading items from system properties. I would put these settings in my domain.xml for GlassFish. What is the Tomcat equivalent? I tried putting settings under my WEB-INF\web.xml file as context-paramsection. However, my GWT application cannot see them still. Where should I put settings that can be read by calling org.apache.commons.configuration.SystemConfiguration from my GWT app from Tomcat? Based on that, you'd want to add system properties in $CATALINA_BASE/bin/setenv.sh. Note this file doesn't exist by default, you'll need to create it. Ex: CATALINA_OPTs=-Dmy.property.1=xyz -Dmy.property.2=abc Dan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Having trouble with common.loader
On Aug 22, 2013, at 9:21 AM, D C dc12...@gmail.com wrote: Ok, here goes. grep -v '/opt/jdk' snip Removing some of the fluff. Aug 21, 2013 5:08:03 PM org.apache.catalina.startup.HostConfig deployDescriptor INFO: Deploying configuration descriptor /opt/apache-tomcat-7.0.40/conf/Catalina/localhost/myApp.xml Ok, myApp is deployed here... [Loaded org.springframework.web.SpringServletContainerInitializer from file:/web/webapps/myApp/WEB-INF/lib/spring-web-3.1.0.RELEASE.jar] [Loaded org.springframework.web.WebApplicationInitializer from file:/web/webapps/myApp/WEB-INF/lib/spring-web-3.1.0.RELEASE.jar] We can see that some of the Spring classes are being loaded from WEB-INF/lib. Were you expecting this? [Loaded org.springframework.web.context.ContextLoader from file:/web/webapps/myApp/WEB-INF/lib/spring-web-3.1.0.RELEASE.jar] [Loaded org.springframework.web.context.ContextLoaderListener from file:/web/webapps/myApp/WEB-INF/lib/spring-web-3.1.0.RELEASE.jar] More Spring classes loaded from WEB-INF/ilb. Again, were you expecting this? [Loaded com.myco.management.spring_utils.ContextLoaderListener from file:/web/webapps/myApp/WEB-INF/classes/com/myco/management/spring_utils/ContextLoaderListener.class] Looks like one of your custom classes is being loaded. No big deal. Aug 21, 2013 5:08:07 PM org.apache.catalina.core.ContainerBase addChildInternal SEVERE: ContainerBase.addChild: start: App start fails... Caused by: java.lang.ClassNotFoundException: org.springframework.core.io.Resource at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1714) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1559) ... 25 more Missing class is org.springframework.core.io.Resource. Where is your spring-core-3.1.0.RELEASE.jar file? Looking further... at org.apache.catalina.util.Introspection.getDeclaredFields(Introspection.java:106) at org.apache.catalina.startup.WebAnnotationSet.loadFieldsAnnotation(WebAnnotationSet.java:261) at org.apache.catalina.startup.WebAnnotationSet.loadApplicationListenerAnnotations(WebAnnotationSet.java:90) at org.apache.catalina.startup.WebAnnotationSet.loadApplicationAnnotations(WebAnnotationSet.java:65) at org.apache.catalina.startup.ContextConfig.applicationAnnotationsConfig(ContextConfig.java:405) at org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:881) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:369) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5269) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) The stack trace seems to indicate that this error occurred while the container was scanning for annotations. Is your application making use of Spring's WebApplicationInitializer functionality? If not, you might want to disable it and see if the error goes away. Dan On Thu, Aug 22, 2013 at 8:58 AM, Daniel Mikusa dmik...@gopivotal.comwrote: On Aug 22, 2013, at 8:38 AM, D C dc12...@gmail.com wrote: [tomcat@test05 logs]# grep from file catalina.out | sed 's/.*from file//g' | sed 's/\/lib\/.*/\/lib/g' | sort -u :/opt/apache-tomcat-7.0.40/bin/bootstrap.jar] :/opt/apache-tomcat-7.0.40/bin/tomcat-juli.jar] :/opt/apache-tomcat-7.0.40/lib :/opt/jdk1.7.0.21/jre/lib :/web/webapps/myApp/WEB-INF/classes/com/myco/management/spring_utils/ContextLoaderListener.class] :/web/webapps/myApp/WEB-INF/lib Can you show the unaltered output? If you want to filter out stuff to make it smaller, filter out any classes that were loaded from the JDK. Dan Thanks, Dan On Thu, Aug 22, 2013 at 6:47 AM, Daniel Mikusa dmik...@gopivotal.com wrote: On Aug 21, 2013, at 5:09 PM, D C dc12...@gmail.com wrote: I added verbose, it does not appear to attempt to load anything from /web/lib/ Ok. Where do you see it loading classes from? /WEB-INF/lib/*.jar? Do you see any classes listed that you would expect to be loaded from /web/lib? Where are they being loaded from? for permissions i verified that i could read the files as the tomcat user. Good Thanks, Dan On Wed, Aug 21, 2013 at 5:01 PM, Daniel Mikusa dmik...@gopivotal.com wrote: On Aug 21, 2013, at 4:48 PM, D C dc12...@gmail.com wrote: So here is what I'm trying to achieve. 1. The tomcat install remains clean. I want to be able to change the tomcat installation without messing with the app. 2. We want our applications to be decoupled from the libraries which it needs. ( i understand the pains you are referring to.. this was a bit of debate, but this is what we want to do). 3. We want our engineering team to manage libs via RPM, not the developers. tomcat is installed
Re: Tomcat connectors and NTFS permission
Asha K S wrote: HI, Tomcat connectors don't seem to honor the NTFS permissions set for the files. Is there a way to achieve this ? Can you be a bit more explicit about what your exact problem is, and maybe list the Tomcat version which you are using, and the Connector which you are talking about ? Right now, I can't really think of a link between Tomcat connectors and NTFS permissions, but I'm willing to be surprised. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Having trouble with common.loader
On Thu, Aug 22, 2013 at 10:30 AM, Daniel Mikusa dmik...@gopivotal.comwrote:
On Aug 22, 2013, at 9:21 AM, D C dc12...@gmail.com wrote:
Ok, here goes. grep -v '/opt/jdk'
snip Removing some of the fluff.
Aug 21, 2013 5:08:03 PM org.apache.catalina.startup.HostConfig
deployDescriptor
INFO: Deploying configuration descriptor
/opt/apache-tomcat-7.0.40/conf/Catalina/localhost/myApp.xml
Ok, myApp is deployed here...
So far working as expected.
[Loaded org.springframework.web.SpringServletContainerInitializer from
file:/web/webapps/myApp/WEB-INF/lib/spring-web-3.1.0.RELEASE.jar]
[Loaded org.springframework.web.WebApplicationInitializer from
file:/web/webapps/myApp/WEB-INF/lib/spring-web-3.1.0.RELEASE.jar]
We can see that some of the Spring classes are being loaded from
WEB-INF/lib. Were you expecting this?
This is an example of something our developers will need to clean up before
we release... But yes it was expected.
[Loaded org.springframework.web.context.ContextLoader from
file:/web/webapps/myApp/WEB-INF/lib/spring-web-3.1.0.RELEASE.jar]
[Loaded org.springframework.web.context.ContextLoaderListener from
file:/web/webapps/myApp/WEB-INF/lib/spring-web-3.1.0.RELEASE.jar]
More Spring classes loaded from WEB-INF/ilb. Again, were you expecting
this?
Yup.
[Loaded com.myco.management.spring_utils.ContextLoaderListener from
file:/web/webapps/myApp/WEB-INF/classes/com/myco/management/spring_utils/ContextLoaderListener.class]
Looks like one of your custom classes is being loaded. No big deal.
Aug 21, 2013 5:08:07 PM org.apache.catalina.core.ContainerBase
addChildInternal
SEVERE: ContainerBase.addChild: start:
App start fails...
Caused by: java.lang.ClassNotFoundException:
org.springframework.core.io.Resource
at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1714)
at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1559)
... 25 more
Missing class is org.springframework.core.io.Resource. Where is your
spring-core-3.1.0.RELEASE.jar file?
/web/lib/spring-core-3.1.0.RELEASE.jar
Looking further...
at
org.apache.catalina.util.Introspection.getDeclaredFields(Introspection.java:106)
at
org.apache.catalina.startup.WebAnnotationSet.loadFieldsAnnotation(WebAnnotationSet.java:261)
at
org.apache.catalina.startup.WebAnnotationSet.loadApplicationListenerAnnotations(WebAnnotationSet.java:90)
at
org.apache.catalina.startup.WebAnnotationSet.loadApplicationAnnotations(WebAnnotationSet.java:65)
at
org.apache.catalina.startup.ContextConfig.applicationAnnotationsConfig(ContextConfig.java:405)
at
org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:881)
at
org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:369)
at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at
org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5269)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
The stack trace seems to indicate that this error occurred while the
container was scanning for annotations. Is your application making use of
Spring's WebApplicationInitializer functionality? If not, you might want
to disable it and see if the error goes away.
Sorry I don't know.
We just tried adding every jar file in /web/lib/ to the classpath and that
seemed to work out, so this brings me back to whats wrong with
common.loader?
common.loader=${catalina.base}/lib,${catalina.base}/lib/*.jar,${catalina.home}/lib,${catalina.home}/lib/*.jar,/web/lib,/web/lib/*.jar
Dan
On Thu, Aug 22, 2013 at 8:58 AM, Daniel Mikusa dmik...@gopivotal.com
wrote:
On Aug 22, 2013, at 8:38 AM, D C dc12...@gmail.com wrote:
[tomcat@test05 logs]# grep from file catalina.out | sed 's/.*from
file//g' | sed 's/\/lib\/.*/\/lib/g' | sort -u
:/opt/apache-tomcat-7.0.40/bin/bootstrap.jar]
:/opt/apache-tomcat-7.0.40/bin/tomcat-juli.jar]
:/opt/apache-tomcat-7.0.40/lib
:/opt/jdk1.7.0.21/jre/lib
:/web/webapps/myApp/WEB-INF/classes/com/myco/management/spring_utils/ContextLoaderListener.class]
:/web/webapps/myApp/WEB-INF/lib
Can you show the unaltered output? If you want to filter out stuff to
make it smaller, filter out any classes that were loaded from the JDK.
Dan
Thanks,
Dan
On Thu, Aug 22, 2013 at 6:47 AM, Daniel Mikusa dmik...@gopivotal.com
wrote:
On Aug 21, 2013, at 5:09 PM, D C dc12...@gmail.com wrote:
I added verbose, it does not appear to attempt to load anything from
/web/lib/
Ok. Where do you see it loading classes from? /WEB-INF/lib/*.jar?
Do
you see any classes listed that you would expect to be loaded from
/web/lib? Where are they being loaded from?
for permissions i verified that i
Re: Migrating from GlassFish to Tomcat 7
2013/8/22 Daniel Mikusa dmik...@gopivotal.com: On Aug 22, 2013, at 8:48 AM, B W bw20130...@gmail.com wrote: I have a GWT application which currently is running on GlassFish 3.x. I want to migrate to Tomcat 7. Previously, I would store properties that the GWT application could retrieve by org.apache.commons.configuration.SystemConfiguration. Looks like this class is loading items from system properties. I would put these settings in my domain.xml for GlassFish. What is the Tomcat equivalent? I tried putting settings under my WEB-INF\web.xml file as context-paramsection. However, my GWT application cannot see them still. Where should I put settings that can be read by calling org.apache.commons.configuration.SystemConfiguration from my GWT app from Tomcat? Based on that, you'd want to add system properties in $CATALINA_BASE/bin/setenv.sh. Note this file doesn't exist by default, you'll need to create it. Ex: CATALINA_OPTS=-Dmy.property.1=xyz -Dmy.property.2=abc Properties that are used by a web application (and not by Java itself during its startup) can also be added to conf/catalina.properties file. http://tomcat.apache.org/tomcat-7.0-doc/config/index.html Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 7.0 logging on different platforms
My development setup is Win7 while my production is RHEL6. Both of the environments have the same settings in conf/logging.properties but the files in logs/ are slightly different. The access logs are named the same way. but on RHEL there's no tomcat7-stdout or tomcat7-stderr log files. Just 'catalina.out.YEAR.MO.DY' and the cumulative catalina.out with no date. What accounts for the differences? Also, how would you stop logging to the 'catalina.out' file. It gets unusably gigantic within a few days. Thanks, Alec
Re: Having trouble with common.loader
2013/8/22 Daniel Mikusa dmik...@gopivotal.com:
On Aug 21, 2013, at 4:09 PM, David kerber dcker...@verizon.net wrote:
Basically you're trying to defeat the way the system is designed to work.
Don't do that…
+1 Don't do what you've described unless you have a very good reason. It
will cause you many headaches.
Keep all of your JAR files in WEB-INF/lib, with the exception of JDBC
drivers. Put those in $CATALINA_BASE/lib.
Dan
1.
+1.
Adding webapp libraries to the common classloader (by placing them
into ${catalina.base}/lib or by modifying the definition of
common.loader) is a bad idea.
(as documented and as discussed many times on this mailing list)
IF you want to decouple libraries from your war, add them to your
webapp's classpath, by configuring a VirtualWebappLoader ,
http://tomcat.apache.org/tomcat-7.0-doc/config/loader.html#VirtualWebappLoader_Implementation
2. Top-posting is bad,
per rules of this mailing list,
http://tomcat.apache.org/lists.html#tomcat-users
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Fwd: Tomcat 7 / Java 7 with TLS 1.2 algorithms
According to RFC 5246 Appendix C (TLS 1.2), there is no SHA384. See : http://www.ietf.org/rfc/rfc5246.txt The JSSE Reference Guide also doesn't talk about this SHA384 as an implementation requirement. See : http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#impl This means you have a problem with SHA256 only. Maybe it's easier to test on client-side, with one of the following ciphers (that you find on the same Reference Guide ) for example : TLS_DH_RSA_WITH_AES_256_CBC_SHA256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 Let me know if this works, or I will try to test by myself with my own client. 2013/8/22 Dennis Sosnoski d...@sosnoski.com: I've already done that, though as far as I can see that doesn't effect the digest algorithms (only the encryption options). - Dennis On 08/23/2013 12:24 AM, Aurélien Terrestris wrote: Hello I suppose you need to run your JVM with the unrestricted policy files (on b= oth client and server sides). You have to download them from Oracle website= for your java version, and replace the old. These files are : local_policy.jar US_export_policy.jar Regards 2013/8/22 d...@sosnoski.com: Tomcat 7.0.40 seems to work well with TLS 1.2, forced by using a sslEnabledProtocols=TLSv1.2 attribute on the Connector. But I haven't been able to make it work with any of the SHA256/384 algorithms - they always show up in the Ignoring unsupported cipher suite list. I get the same thing happening when I try to use them from client code, so I know it's not a Tomcat issue, but I'm hoping someone knows a workaround. Any suggestions? Thanks, - Dennis - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7.0 logging on different platforms
On 22/08/2013 16:44, Tomcat Random wrote: My development setup is Win7 while my production is RHEL6. Both of the environments have the same settings in conf/logging.properties but the files in logs/ are slightly different. The access logs are named the same way. but on RHEL there's no tomcat7-stdout or tomcat7-stderr log files. Just 'catalina.out.YEAR.MO.DY' and the cumulative catalina.out with no date. What accounts for the differences? The Windows service wrapper vs. catalina.sh Also, how would you stop logging to the 'catalina.out' file. It gets unusably gigantic within a few days. Remove the console logger from logging.properties Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7.0 logging on different platforms
2013/8/22 Tomcat Random tomcat.ran...@gmail.com: My development setup is Win7 while my production is RHEL6. Both of the environments have the same settings in conf/logging.properties but the files in logs/ are slightly different. The access logs are named the same way. but on RHEL there's no tomcat7-stdout or tomcat7-stderr log files. Just 'catalina.out.YEAR.MO.DY' and the cumulative catalina.out with no date. What accounts for the differences? catalina.sh redirects stderr to stdout with 21 and logs them to the same file Windows service wrapper (Apache Commons Daemon procrun) logs them to separate files. Also, how would you stop logging to the 'catalina.out' file. It gets unusably gigantic within a few days. Just do not write to the console. http://tomcat.apache.org/tomcat-7.0-doc/logging.html#Considerations_for_productive_usage Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Having trouble with common.loader
On Aug 22, 2013, at 11:31 AM, D C dc12...@gmail.com wrote:
On Thu, Aug 22, 2013 at 10:30 AM, Daniel Mikusa dmik...@gopivotal.comwrote:
On Aug 22, 2013, at 9:21 AM, D C dc12...@gmail.com wrote:
Ok, here goes. grep -v '/opt/jdk'
snip Removing some of the fluff.
Aug 21, 2013 5:08:03 PM org.apache.catalina.startup.HostConfig
deployDescriptor
INFO: Deploying configuration descriptor
/opt/apache-tomcat-7.0.40/conf/Catalina/localhost/myApp.xml
Ok, myApp is deployed here...
So far working as expected.
[Loaded org.springframework.web.SpringServletContainerInitializer from
file:/web/webapps/myApp/WEB-INF/lib/spring-web-3.1.0.RELEASE.jar]
[Loaded org.springframework.web.WebApplicationInitializer from
file:/web/webapps/myApp/WEB-INF/lib/spring-web-3.1.0.RELEASE.jar]
We can see that some of the Spring classes are being loaded from
WEB-INF/lib. Were you expecting this?
This is an example of something our developers will need to clean up before
we release... But yes it was expected.
[Loaded org.springframework.web.context.ContextLoader from
file:/web/webapps/myApp/WEB-INF/lib/spring-web-3.1.0.RELEASE.jar]
[Loaded org.springframework.web.context.ContextLoaderListener from
file:/web/webapps/myApp/WEB-INF/lib/spring-web-3.1.0.RELEASE.jar]
More Spring classes loaded from WEB-INF/ilb. Again, were you expecting
this?
Yup.
[Loaded com.myco.management.spring_utils.ContextLoaderListener from
file:/web/webapps/myApp/WEB-INF/classes/com/myco/management/spring_utils/ContextLoaderListener.class]
Looks like one of your custom classes is being loaded. No big deal.
Aug 21, 2013 5:08:07 PM org.apache.catalina.core.ContainerBase
addChildInternal
SEVERE: ContainerBase.addChild: start:
App start fails...
Caused by: java.lang.ClassNotFoundException:
org.springframework.core.io.Resource
at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1714)
at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1559)
... 25 more
Missing class is org.springframework.core.io.Resource. Where is your
spring-core-3.1.0.RELEASE.jar file?
/web/lib/spring-core-3.1.0.RELEASE.jar
Looking further...
at
org.apache.catalina.util.Introspection.getDeclaredFields(Introspection.java:106)
at
org.apache.catalina.startup.WebAnnotationSet.loadFieldsAnnotation(WebAnnotationSet.java:261)
at
org.apache.catalina.startup.WebAnnotationSet.loadApplicationListenerAnnotations(WebAnnotationSet.java:90)
at
org.apache.catalina.startup.WebAnnotationSet.loadApplicationAnnotations(WebAnnotationSet.java:65)
at
org.apache.catalina.startup.ContextConfig.applicationAnnotationsConfig(ContextConfig.java:405)
at
org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:881)
at
org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:369)
at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at
org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5269)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
The stack trace seems to indicate that this error occurred while the
container was scanning for annotations. Is your application making use of
Spring's WebApplicationInitializer functionality? If not, you might want
to disable it and see if the error goes away.
Sorry I don't know.
Try disabling it and see what happens.
Edit conf/catalina.properties and set
org.apache.catalina.startup.ContextConfig.jarsToSkip to spring-*.jar. That
should instruct Tomcat to skip processing the Spring jar files for Servlet 3.0
pluggability features like web fragments, annotations SCIs.
We just tried adding every jar file in /web/lib/ to the class path
What do you mean by this? How did you add them to the class path? Did you
copy them into WEB-INF/lib?
and that seemed to work out, so this brings me back to whats wrong with
common.loader?
common.loader=${catalina.base}/lib,${catalina.base}/lib/*.jar,${catalina.home}/lib,${catalina.home}/lib/*.jar,/web/lib,/web/lib/*.jar
Syntax looks fine to me. As myself and others mentioned originally, sharing
classes with the common class loader causes lots of headaches. I would say
that you've found one here.
A suggestion for debugging further, remove the -verbose JVM argument and set
the log level for org.apache.catalina.loader.WebappClassLoader to FINE. The
WebappClassLoader has some debugging information that it should write to the
logs. This could give us further clues as to what is happening.
Dan
Dan
On Thu, Aug 22, 2013 at 8:58 AM, Daniel Mikusa dmik...@gopivotal.com
wrote:
On Aug 22, 2013, at 8:38 AM, D C dc12...@gmail.com wrote:
[tomcat@test05 logs]# grep from file catalina.out | sed 's/.*from
file//g' |
Re: Having trouble with common.loader
On Thu, Aug 22, 2013 at 11:57 AM, Daniel Mikusa dmik...@gopivotal.comwrote:
On Aug 22, 2013, at 11:31 AM, D C dc12...@gmail.com wrote:
On Thu, Aug 22, 2013 at 10:30 AM, Daniel Mikusa dmik...@gopivotal.com
wrote:
On Aug 22, 2013, at 9:21 AM, D C dc12...@gmail.com wrote:
Ok, here goes. grep -v '/opt/jdk'
snip Removing some of the fluff.
Aug 21, 2013 5:08:03 PM org.apache.catalina.startup.HostConfig
deployDescriptor
INFO: Deploying configuration descriptor
/opt/apache-tomcat-7.0.40/conf/Catalina/localhost/myApp.xml
Ok, myApp is deployed here...
So far working as expected.
[Loaded org.springframework.web.SpringServletContainerInitializer from
file:/web/webapps/myApp/WEB-INF/lib/spring-web-3.1.0.RELEASE.jar]
[Loaded org.springframework.web.WebApplicationInitializer from
file:/web/webapps/myApp/WEB-INF/lib/spring-web-3.1.0.RELEASE.jar]
We can see that some of the Spring classes are being loaded from
WEB-INF/lib. Were you expecting this?
This is an example of something our developers will need to clean up
before
we release... But yes it was expected.
[Loaded org.springframework.web.context.ContextLoader from
file:/web/webapps/myApp/WEB-INF/lib/spring-web-3.1.0.RELEASE.jar]
[Loaded org.springframework.web.context.ContextLoaderListener from
file:/web/webapps/myApp/WEB-INF/lib/spring-web-3.1.0.RELEASE.jar]
More Spring classes loaded from WEB-INF/ilb. Again, were you expecting
this?
Yup.
[Loaded com.myco.management.spring_utils.ContextLoaderListener from
file:/web/webapps/myApp/WEB-INF/classes/com/myco/management/spring_utils/ContextLoaderListener.class]
Looks like one of your custom classes is being loaded. No big deal.
Aug 21, 2013 5:08:07 PM org.apache.catalina.core.ContainerBase
addChildInternal
SEVERE: ContainerBase.addChild: start:
App start fails...
Caused by: java.lang.ClassNotFoundException:
org.springframework.core.io.Resource
at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1714)
at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1559)
... 25 more
Missing class is org.springframework.core.io.Resource. Where is your
spring-core-3.1.0.RELEASE.jar file?
/web/lib/spring-core-3.1.0.RELEASE.jar
Looking further...
at
org.apache.catalina.util.Introspection.getDeclaredFields(Introspection.java:106)
at
org.apache.catalina.startup.WebAnnotationSet.loadFieldsAnnotation(WebAnnotationSet.java:261)
at
org.apache.catalina.startup.WebAnnotationSet.loadApplicationListenerAnnotations(WebAnnotationSet.java:90)
at
org.apache.catalina.startup.WebAnnotationSet.loadApplicationAnnotations(WebAnnotationSet.java:65)
at
org.apache.catalina.startup.ContextConfig.applicationAnnotationsConfig(ContextConfig.java:405)
at
org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:881)
at
org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:369)
at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at
org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5269)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
The stack trace seems to indicate that this error occurred while the
container was scanning for annotations. Is your application making use
of
Spring's WebApplicationInitializer functionality? If not, you might
want
to disable it and see if the error goes away.
Sorry I don't know.
Try disabling it and see what happens.
Edit conf/catalina.properties and set
org.apache.catalina.startup.ContextConfig.jarsToSkip to spring-*.jar.
That should instruct Tomcat to skip processing the Spring jar files for
Servlet 3.0 pluggability features like web fragments, annotations SCIs.
We just tried adding every jar file in /web/lib/ to the class path
What do you mean by this? How did you add them to the class path? Did
you copy them into WEB-INF/lib?
No the environment variable in setenv.sh
CLASSPATH=every jar
and that seemed to work out, so this brings me back to whats wrong with
common.loader?
common.loader=${catalina.base}/lib,${catalina.base}/lib/*.jar,${catalina.home}/lib,${catalina.home}/lib/*.jar,/web/lib,/web/lib/*.jar
Syntax looks fine to me. As myself and others mentioned originally,
sharing classes with the common class loader causes lots of headaches. I
would say that you've found one here.
A suggestion for debugging further, remove the -verbose JVM argument and
set the log level for org.apache.catalina.loader.WebappClassLoader to FINE.
The WebappClassLoader has some debugging information that it should write
to the logs. This could give us further clues as to what is
Re: Having trouble with common.loader
On Thu, Aug 22, 2013 at 11:48 AM, Konstantin Kolinko knst.koli...@gmail.com
wrote:
2013/8/22 Daniel Mikusa dmik...@gopivotal.com:
On Aug 21, 2013, at 4:09 PM, David kerber dcker...@verizon.net wrote:
Basically you're trying to defeat the way the system is designed to
work. Don't do that…
+1 Don't do what you've described unless you have a very good reason.
It will cause you many headaches.
Keep all of your JAR files in WEB-INF/lib, with the exception of JDBC
drivers. Put those in $CATALINA_BASE/lib.
Dan
1.
+1.
Adding webapp libraries to the common classloader (by placing them
into ${catalina.base}/lib or by modifying the definition of
common.loader) is a bad idea.
(as documented and as discussed many times on this mailing list)
IF you want to decouple libraries from your war, add them to your
webapp's classpath, by configuring a VirtualWebappLoader ,
http://tomcat.apache.org/tomcat-7.0-doc/config/loader.html#VirtualWebappLoader_Implementation
Interesting. I just tried this out, but I'm not having luck.
We load the context of the app from
$catalina_home/conf/Catalina/localhost/myApp.xml
I tried adding the Loader to my context so it looks like this. Am I doing
something wrong.
?xml version='1.0' encoding='utf-8'?
Context
Loader className=org.apache.catalina.loader.VirtualWebappLoader
virtualClasspath=/web/lib;/web/lib/*.jar/
Resource
factory=org.apache.tomcat.jdbc.pool.DataSourceFactory
...
2. Top-posting is bad,
per rules of this mailing list,
http://tomcat.apache.org/lists.html#tomcat-users
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Having trouble with common.loader
On Aug 22, 2013, at 12:32 PM, D C dc12...@gmail.com wrote:
On Thu, Aug 22, 2013 at 11:57 AM, Daniel Mikusa dmik...@gopivotal.comwrote:
On Aug 22, 2013, at 11:31 AM, D C dc12...@gmail.com wrote:
On Thu, Aug 22, 2013 at 10:30 AM, Daniel Mikusa dmik...@gopivotal.com
wrote:
On Aug 22, 2013, at 9:21 AM, D C dc12...@gmail.com wrote:
Ok, here goes. grep -v '/opt/jdk'
snip Removing some of the fluff.
Aug 21, 2013 5:08:03 PM org.apache.catalina.startup.HostConfig
deployDescriptor
INFO: Deploying configuration descriptor
/opt/apache-tomcat-7.0.40/conf/Catalina/localhost/myApp.xml
Ok, myApp is deployed here...
So far working as expected.
[Loaded org.springframework.web.SpringServletContainerInitializer from
file:/web/webapps/myApp/WEB-INF/lib/spring-web-3.1.0.RELEASE.jar]
[Loaded org.springframework.web.WebApplicationInitializer from
file:/web/webapps/myApp/WEB-INF/lib/spring-web-3.1.0.RELEASE.jar]
We can see that some of the Spring classes are being loaded from
WEB-INF/lib. Were you expecting this?
This is an example of something our developers will need to clean up
before
we release... But yes it was expected.
[Loaded org.springframework.web.context.ContextLoader from
file:/web/webapps/myApp/WEB-INF/lib/spring-web-3.1.0.RELEASE.jar]
[Loaded org.springframework.web.context.ContextLoaderListener from
file:/web/webapps/myApp/WEB-INF/lib/spring-web-3.1.0.RELEASE.jar]
More Spring classes loaded from WEB-INF/ilb. Again, were you expecting
this?
Yup.
[Loaded com.myco.management.spring_utils.ContextLoaderListener from
file:/web/webapps/myApp/WEB-INF/classes/com/myco/management/spring_utils/ContextLoaderListener.class]
Looks like one of your custom classes is being loaded. No big deal.
Aug 21, 2013 5:08:07 PM org.apache.catalina.core.ContainerBase
addChildInternal
SEVERE: ContainerBase.addChild: start:
App start fails...
Caused by: java.lang.ClassNotFoundException:
org.springframework.core.io.Resource
at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1714)
at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1559)
... 25 more
Missing class is org.springframework.core.io.Resource. Where is your
spring-core-3.1.0.RELEASE.jar file?
/web/lib/spring-core-3.1.0.RELEASE.jar
Looking further...
at
org.apache.catalina.util.Introspection.getDeclaredFields(Introspection.java:106)
at
org.apache.catalina.startup.WebAnnotationSet.loadFieldsAnnotation(WebAnnotationSet.java:261)
at
org.apache.catalina.startup.WebAnnotationSet.loadApplicationListenerAnnotations(WebAnnotationSet.java:90)
at
org.apache.catalina.startup.WebAnnotationSet.loadApplicationAnnotations(WebAnnotationSet.java:65)
at
org.apache.catalina.startup.ContextConfig.applicationAnnotationsConfig(ContextConfig.java:405)
at
org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:881)
at
org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:369)
at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at
org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5269)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
The stack trace seems to indicate that this error occurred while the
container was scanning for annotations. Is your application making use
of
Spring's WebApplicationInitializer functionality? If not, you might
want
to disable it and see if the error goes away.
Sorry I don't know.
Try disabling it and see what happens.
Edit conf/catalina.properties and set
org.apache.catalina.startup.ContextConfig.jarsToSkip to spring-*.jar.
That should instruct Tomcat to skip processing the Spring jar files for
Servlet 3.0 pluggability features like web fragments, annotations SCIs.
We just tried adding every jar file in /web/lib/ to the class path
What do you mean by this? How did you add them to the class path? Did
you copy them into WEB-INF/lib?
No the environment variable in setenv.sh
CLASSPATH=every jar
I'm surprise that actually worked. The catalina script will typically ignore
attempts to set CLASSPATH directly. I would really, really suggest you don't
do this.
and that seemed to work out, so this brings me back to whats wrong with
common.loader?
common.loader=${catalina.base}/lib,${catalina.base}/lib/*.jar,${catalina.home}/lib,${catalina.home}/lib/*.jar,/web/lib,/web/lib/*.jar
Syntax looks fine to me. As myself and others mentioned originally,
sharing classes with the common class loader causes lots of headaches. I
would say that you've found one here.
A suggestion for debugging further, remove the -verbose JVM argument and
set the log level for
Re: standalone use of Tomcat 8 websocket-api.jar getWebSocketContainer returning null
On 22/08/2013 17:39, Bob DeRemer wrote: I’m trying to use the Tomcat8 jsr client functionality in a standalone java client. I’m trying to use the minimal number of jars, so I gabbed websocket-api.jar ONLY. When I call ContainerProvider.getWebSocketContainer(), it returns null. Do I need another jar to resolve this on the client? Yes. You need tomcat-websocket.jar (the implementation) and its dependencies (tomcat-juli.jar and tomcat-util.jar). It is possible to split the implementation into client and server but we haven't done that. It isn't like the JARs are that big anyway. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: standalone use of Tomcat 8 websocket-api.jar getWebSocketContainer returning null
-Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Thursday, August 22, 2013 1:37 PM To: Tomcat Users List Subject: Re: standalone use of Tomcat 8 websocket-api.jar getWebSocketContainer returning null On 22/08/2013 17:39, Bob DeRemer wrote: I'm trying to use the Tomcat8 jsr client functionality in a standalone java client. I'm trying to use the minimal number of jars, so I gabbed websocket-api.jar ONLY. When I call ContainerProvider.getWebSocketContainer(), it returns null. Do I need another jar to resolve this on the client? Yes. You need tomcat-websocket.jar (the implementation) and its dependencies (tomcat-juli.jar and tomcat-util.jar). It is possible to split the implementation into client and server but we haven't done that. It isn't like the JARs are that big anyway. Not a problem, I just wanted to figure out the minimal as opposed to taking all of them -thx Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
is it possible to dynamically add servlets and websocket endpoints during startup based on our own configuration settings?
I'm in the process of developing a configurable server application which must handle various protocols, but the respective endpoints must be configurable. Specifically, I would like to programmatically add both HTTP servlet(s) as well as WebSocket Servlets/Endpoints during the contextInitialized call [based on our own configuration settings], as opposed to having all servlets in web.xml or annotated classes loaded automatically. Is this possible in Tomcat 7; and, if yes, are there any examples? I know the Endpoint aspect of the question depends on JSR-356 being back-ported. Thanks, Bob DeRemer Senior Director, Architecture and Development [Description: Description: Description: Description: cid:image001.png@01CBE3DE.51A12030] http://www.thingworx.comhttp://www.thingworx.com/ Skype: bob.deremer.thingworx O: 610.594.6200 x812 M: 717.881.3986
Re: Having trouble with common.loader
2013/8/22 D C dc12...@gmail.com:
On Thu, Aug 22, 2013 at 11:48 AM, Konstantin Kolinko knst.koli...@gmail.com
wrote:
2013/8/22 Daniel Mikusa dmik...@gopivotal.com:
On Aug 21, 2013, at 4:09 PM, David kerber dcker...@verizon.net wrote:
Basically you're trying to defeat the way the system is designed to
work. Don't do that…
+1 Don't do what you've described unless you have a very good reason.
It will cause you many headaches.
Keep all of your JAR files in WEB-INF/lib, with the exception of JDBC
drivers. Put those in $CATALINA_BASE/lib.
Dan
1.
+1.
Adding webapp libraries to the common classloader (by placing them
into ${catalina.base}/lib or by modifying the definition of
common.loader) is a bad idea.
(as documented and as discussed many times on this mailing list)
IF you want to decouple libraries from your war, add them to your
webapp's classpath, by configuring a VirtualWebappLoader ,
http://tomcat.apache.org/tomcat-7.0-doc/config/loader.html#VirtualWebappLoader_Implementation
Interesting. I just tried this out, but I'm not having luck.
We load the context of the app from
$catalina_home/conf/Catalina/localhost/myApp.xml
I tried adding the Loader to my context so it looks like this. Am I doing
something wrong.
?xml version='1.0' encoding='utf-8'?
Context
Loader className=org.apache.catalina.loader.VirtualWebappLoader
virtualClasspath=/web/lib;/web/lib/*.jar/
Looks OK, if those paths are correct.
You can enable debug logging for that class and it will list whatever
jars it finds.
Is the following shell command able to list your jar files?
ls /web/lib/
/opt/tomcat-6.0.35
/opt/tomcat-7.0.39
/opt/tomcat-7.0.40
/tomcat symlinks to which ever /opt/tomcat-7.0.40
You are using 7.0.40, 7.0.42, or some ancient version?
Do you know how configure Tomcat with separate $CATALINA_BASE and
$CATALINA_HOME?
Do they have the same value for you, or different ones? (As printed by
catalina.sh just before Tomcat starts).
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Having trouble with common.loader
Am 2013-08-22 17:48, schrieb Konstantin Kolinko:
2013/8/22 Daniel Mikusa dmik...@gopivotal.com:
On Aug 21, 2013, at 4:09 PM, David kerber dcker...@verizon.net wrote:
Basically you're trying to defeat the way the system is designed to work.
Don't do that…
+1 Don't do what you've described unless you have a very good reason. It will
cause you many headaches.
Keep all of your JAR files in WEB-INF/lib, with the exception of JDBC drivers. Put
those in $CATALINA_BASE/lib.
Dan
1.
+1.
Adding webapp libraries to the common classloader (by placing them
into ${catalina.base}/lib or by modifying the definition of
common.loader) is a bad idea.
(as documented and as discussed many times on this mailing list)
IF you want to decouple libraries from your war, add them to your
webapp's classpath, by configuring a VirtualWebappLoader ,
http://tomcat.apache.org/tomcat-7.0-doc/config/loader.html#VirtualWebappLoader_Implementation
Very decent tip for this loader. Does the Javadoc warning
This is not meant to be used for production. Its meant to ease
development with IDE's without the need for fully republishing jars in
WEB-INF/lib
still count?
Michael
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: standalone use of Tomcat 8 websocket-api.jar getWebSocketContainer returning null
On Thu, Aug 22, 2013 at 7:39 PM, Bob DeRemer bob.dere...@thingworx.comwrote: I’m trying to use the Tomcat8 jsr client functionality in a standalone java client. I’m trying to use the minimal number of jars, so I gabbed websocket-api.jar ONLY. When I call ContainerProvider.getWebSocketContainer(), it returns null. ** ** Do I need another jar to resolve this on the client? Yes. The complete list is: tomcat-websocket-api, tomcat-websocket, tomcat-util tomcat-coyote tomcat-juli Here you can find an example https://github.com/nickytd/websocket-message-handlers-example* * * * ** Thanks, ** ** *Bob DeRemer* *Senior Director, Architecture and Development* ** ** [image: Description: Description: Description: Description: cid:image001.png@01CBE3DE.51A12030] http://www.thingworx.com Skype: bob.deremer.thingworx O: 610.594.6200 x812 M: 717.881.3986 ** **
Re: standalone use of Tomcat 8 websocket-api.jar getWebSocketContainer returning null
On Thu, Aug 22, 2013 at 10:07 PM, Niki Dokovski nick...@gmail.com wrote: On Thu, Aug 22, 2013 at 7:39 PM, Bob DeRemer bob.dere...@thingworx.comwrote: I’m trying to use the Tomcat8 jsr client functionality in a standalone java client. I’m trying to use the minimal number of jars, so I gabbed websocket-api.jar ONLY. When I call ContainerProvider.getWebSocketContainer(), it returns null. ** ** Do I need another jar to resolve this on the client? Yes. The complete list is: tomcat-websocket-api, tomcat-websocket, tomcat-util tomcat-coyote tomcat-juli Here you can find an example https://github.com/nickytd/websocket-message-handlers-example* * Ops didn't see Mark's response ... * * * * ** Thanks, ** ** *Bob DeRemer* *Senior Director, Architecture and Development* ** ** [image: Description: Description: Description: Description: cid:image001.png@01CBE3DE.51A12030] http://www.thingworx.com Skype: bob.deremer.thingworx O: 610.594.6200 x812 M: 717.881.3986 ** **
RE: Having trouble with common.loader
From: Michael-O [mailto:1983-01...@gmx.net] Subject: Re: Having trouble with common.loader IF you want to decouple libraries from your war, add them to your webapp's classpath, by configuring a VirtualWebappLoader , http://tomcat.apache.org/tomcat-7.0-doc/config/loader.html#VirtualWebappLoader_Implementation Very decent tip for this loader. Does the Javadoc warning This is not meant to be used for production. Its meant to ease development with IDE's without the need for fully republishing jars in WEB-INF/lib still count? No. That statement was removed from the doc: http://tomcat.apache.org/tomcat-7.0-doc/config/loader.html and the Javadoc some time ago. Use the current information. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Having trouble with common.loader
Am 2013-08-22 21:40, schrieb Caldarale, Charles R: From: Michael-O [mailto:1983-01...@gmx.net] Subject: Re: Having trouble with common.loader IF you want to decouple libraries from your war, add them to your webapp's classpath, by configuring a VirtualWebappLoader , http://tomcat.apache.org/tomcat-7.0-doc/config/loader.html#VirtualWebappLoader_Implementation Very decent tip for this loader. Does the Javadoc warning This is not meant to be used for production. Its meant to ease development with IDE's without the need for fully republishing jars in WEB-INF/lib still count? No. That statement was removed from the doc: http://tomcat.apache.org/tomcat-7.0-doc/config/loader.html and the Javadoc some time ago. Use the current information. True, it's gone for Tomcat 7. One (I) should file a ticket for that. Thanks, Michael - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Migrating from GlassFish to Tomcat 7
What is the advantage to using catalina.properties vs setenv.sh? On Thu, Aug 22, 2013 at 11:37 AM, Konstantin Kolinko knst.koli...@gmail.com wrote: 2013/8/22 Daniel Mikusa dmik...@gopivotal.com: On Aug 22, 2013, at 8:48 AM, B W bw20130...@gmail.com wrote: I have a GWT application which currently is running on GlassFish 3.x. I want to migrate to Tomcat 7. Previously, I would store properties that the GWT application could retrieve by org.apache.commons.configuration.SystemConfiguration. Looks like this class is loading items from system properties. I would put these settings in my domain.xml for GlassFish. What is the Tomcat equivalent? I tried putting settings under my WEB-INF\web.xml file as context-paramsection. However, my GWT application cannot see them still. Where should I put settings that can be read by calling org.apache.commons.configuration.SystemConfiguration from my GWT app from Tomcat? Based on that, you'd want to add system properties in $CATALINA_BASE/bin/setenv.sh. Note this file doesn't exist by default, you'll need to create it. Ex: CATALINA_OPTS=-Dmy.property.1=xyz -Dmy.property.2=abc Properties that are used by a web application (and not by Java itself during its startup) can also be added to conf/catalina.properties file. http://tomcat.apache.org/tomcat-7.0-doc/config/index.html 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 7 / Java 7 with TLS 1.2 algorithms
point of confusion Eric Rescorla specifically cites SHA384 in his cipher examples for TLS 1.2 Update http://www.ietf.org/rfc/rfc5246.txt http://www.ietf.org/proceedings/70/slides/tls-0.pdf Kuat Eshengazin used bltest as a test harness for SHA384 bltest -R -m prf_sha384 -k tests/prf_sha384/key0 -t tests/prf_sha384/seed0 -h -g 148 -x https://bugzilla.mozilla.org/show_bug.cgi?id=480514 Is this incorrect? Martin __ Please do not alter or disrupt this transmission..Thank You Date: Thu, 22 Aug 2013 14:53:55 +0100 Subject: Re: Tomcat 7 / Java 7 with TLS 1.2 algorithms From: aterrest...@gmail.com To: users@tomcat.apache.org According to RFC 5246 Appendix C (TLS 1.2), there is no SHA384. See : http://www.ietf.org/rfc/rfc5246.txt The JSSE Reference Guide also doesn't talk about this SHA384 as an implementation requirement. See : http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#impl This means you have a problem with SHA256 only. Maybe it's easier to test on client-side, with one of the following ciphers (that you find on the same Reference Guide ) for example : TLS_DH_RSA_WITH_AES_256_CBC_SHA256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 Let me know if this works, or I will try to test by myself with my own client. 2013/8/22 Dennis Sosnoski d...@sosnoski.com: I've already done that, though as far as I can see that doesn't effect the digest algorithms (only the encryption options). - Dennis On 08/23/2013 12:24 AM, Aurélien Terrestris wrote: Hello I suppose you need to run your JVM with the unrestricted policy files (on b= oth client and server sides). You have to download them from Oracle website= for your java version, and replace the old. These files are : local_policy.jar US_export_policy.jar Regards 2013/8/22 d...@sosnoski.com: Tomcat 7.0.40 seems to work well with TLS 1.2, forced by using a sslEnabledProtocols=TLSv1.2 attribute on the Connector. But I haven't been able to make it work with any of the SHA256/384 algorithms - they always show up in the Ignoring unsupported cipher suite list. I get the same thing happening when I try to use them from client code, so I know it's not a Tomcat issue, but I'm hoping someone knows a workaround. Any suggestions? Thanks, - Dennis - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Migrating from GlassFish to Tomcat 7
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 B W, On 8/22/13 4:30 PM, B W wrote: What is the advantage to using catalina.properties vs setenv.sh? If you use setenv.sh, then those system properties will only be available if you use the Tomcat scripts to launch. If you use jsvc or the Microsoft Windows Service Wrapper, they will not be available. Using catalina.properties should allow you to set system properties that will be loaded regardless of how you launch Tomcat. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSFpD/AAoJEBzwKT+lPKRYvbEQALWOa8chxGNMyDTb7032vnnX iMgD0bdTyfXKHQUpseCikP185gksIXdBajxHKNyKH6lDEJLyl4udHg8dtAAPPlmZ FvveRHCuyxlcZXg3qAe7Zsnd83fPVMa5F/ysGDUHUbNIKSAq8YiQtFsnujLRQrKY Y+LZdoDMFbS6wNohBaxIQZtsjiOWu+/JblUAcqwOZ6JV0ZhCl6vhtGgp10UFxsjx BRz5hE6K8vZcYt2zvVGqB9+Kjy7APIPBB1TJTnp8ieA5Y6+Va/6wCtI6ve1FsH83 aj4aEzOejHx5x7shGvz8yr8LfbGGBfRBvHVwVteicffAiBvEPx+5C/t29nR0xJcn wvojyA5oSD5/O+W24mrgf27fmsY8JrgivZsnaSPyx2dHp31bbhkfQz7+FI0Hoh02 jNzNRoRKECOtmxWH/qI9zd9igOa3Merve1e6x0JWtoT9UOY7YFZRRl0jwDoTM75a Ogs0c/kKOlpb57/8iXpffMl9LHD54tCD+XgVb+Dlln7+aSic56eCx+edGqm241fe bWtB9o8nOsjzERjwwlkFFyZsXo1cfJza2LOlNSrsJjx+10KT+3cGxwBt+ywn5Q5j AhYX/YO8WkdCxei2DcZleFYzuuUyInmHnezoxDHvPfZSOzoPvbXfzyZQP8flSvgQ /Q2Pj4X4p65yhV/7s4bj =h6mX -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 8 Websocket API - Cookies Headers
I'm trying to figure out how to get access to the cookies and headers passed up in the Websocket handshake request on Tomcat 8. In Tomcat 7 the whole HttpServletRequest was passed into the WebSocketServlet. createWebSocketInbound method so it was easy to grab from the request headers. In Tomcat 8 the querystring and URI are both exposed by the javax.websocket.Session passed to ServerEndPoint.onOpen, but I don't see a mechanism for getting the cookies or headers. We are integrating Websocket connections into an existing web app and want to use the cookies set by our web app in the Websocket connection process. Thanks for any insight. Todd - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Fwd: Tomcat 7 / Java 7 with TLS 1.2 algorithms
Thanks, Aurélien. I'd seen the SHA384 versions listed in the JSSE Cipher
Suite Names and thought they were available:
http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#ciphersuites
I was really hoping to use one of the GCM suites, but I gather those are
not officially approved yet either: http://tools.ietf.org/html/rfc5288
It appears there is growing support for these in the world, even if
they're not yet an official part of TLS 1.2.
On the client side, this:
SSLContext context = SSLContext.getInstance(TLS);
context.init(null, new TrustManager[] { tm }, null);
SSLParameters params = context.getSupportedSSLParameters();
String[] suites = params.getCipherSuites();
System.out.println(Connecting with + suites.length +
cipher suites supported:);
for (int i = 0; i suites.length; i++) {
System.out.print(' ');
System.out.println(suites[i]);
}
gives me a list of supported cipher suites including:
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
...
but when I try to connect using the socket factory from the context I
get the ssl debug information:
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
...
where all the variations using SHA256 or SHA384 are in this second list.
But explicitly setting a suite like:
System.setProperty(https.cipherSuites,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256);
works, while the SHA384 version fails with Unsupported ciphersuite (as
does any version I've tried using GCM in place of CBC).
I thought JSSE would use the JCE algorithms from BouncyCastle, but it
looks like this doesn't work. I'll have to dig into the JSSE code to see
what's going wrong on that part.
- Dennis
On 08/23/2013 03:48 AM, Aurélien Terrestris wrote:
According to RFC 5246 Appendix C (TLS 1.2), there is no SHA384. See :
http://www.ietf.org/rfc/rfc5246.txt
The JSSE Reference Guide also doesn't talk about this SHA384 as an
implementation requirement. See :
http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#impl
This means you have a problem with SHA256 only. Maybe it's easier to
test on client-side, with one of the following ciphers (that you find
on the same Reference Guide ) for example :
TLS_DH_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
Let me know if this works, or I will try to test by myself with my own client.
2013/8/22 Dennis Sosnoski d...@sosnoski.com:
I've already done that, though as far as I can see that doesn't effect the
digest algorithms (only the encryption options).
- Dennis
On 08/23/2013 12:24 AM, Aurélien Terrestris wrote:
Hello
I suppose you need to run your JVM with the unrestricted policy files (on
b=
oth client and server sides). You have to download them from Oracle
website=
for your java version, and replace the old.
These files are :
local_policy.jar
US_export_policy.jar
Regards
2013/8/22 d...@sosnoski.com:
Tomcat 7.0.40 seems to work well with TLS 1.2, forced by using a
sslEnabledProtocols=TLSv1.2 attribute on the Connector. But I haven't
been able to make it work with any of the SHA256/384 algorithms - they
always show up in the Ignoring unsupported cipher suite list. I get the
same thing happening when I try to use them from client code, so I know it's
not a Tomcat issue, but I'm hoping someone knows a workaround.
Any suggestions?
Thanks,
- Dennis
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
what if I lost the keystore which generate the CSR
Sorry I am a beginner about ssl cert. according to http://tomcat.apache.org/tomcat-7.0-doc/ssl-howto.html#Create_a_local_Certificate_Signing_Request_(CSR) it will gen a keystore and CSR. we generate the CSR and send to Certificate Authority. What if I lost the keystore ? should I regen the CSR again to reapply the ssl cert? Refer to https://search.thawte.com/support/ssl-digital-certificates/index?page=contentid=SO832 It will generate a new keystore file. is it the file store the private key? which stated in https://search.thawte.com/support/ssl-digital-certificates/index?page=contentid=SO750 , which say 1. Private Key file loss. 2. Private Key pass phrase loss. 3. Private Key file has been compromised due to the server being hacked. .. ..
Re: Tomcat 8 Websocket API - Cookies Headers
On Fri, Aug 23, 2013 at 2:58 AM, toddfas todd...@gmail.com wrote: I'm trying to figure out how to get access to the cookies and headers passed up in the Websocket handshake request on Tomcat 8. In Tomcat 7 the whole HttpServletRequest was passed into the WebSocketServlet. createWebSocketInbound method so it was easy to grab from the request headers. In Tomcat 8 the querystring and URI are both exposed by the javax.websocket.Session passed to ServerEndPoint.onOpen, but I don't see a mechanism for getting the cookies or headers. You can supply an extension of http://docs.oracle.com/javaee/7/api/javax/websocket/server/ServerEndpointConfig.Configurator.html and get http://docs.oracle.com/javaee/7/api/javax/websocket/server/HandshakeRequest.html through modifyHandshake invoked by the container during processing of client 'GET' handshake message. Handshake request containes methods for inspecting the http request parameters and headers. We are integrating Websocket connections into an existing web app and want to use the cookies set by our web app in the Websocket connection process. Thanks for any insight. Todd - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
