Re: documentation comment about jndi realms
On Oct 19, 2012, at 11:07 AM, Robert J. Carr wrote:
> I've been using tomcat for many years (so thanks to the devs!) but
> this is the first time I've had to use LDAP for authentication.
> Reading over the docs on this page were very useful:
>
> http://tomcat.apache.org/tomcat-7.0-doc/realm-howto.html#JNDIRealm
>
> However, at the bottom of the section where it talks about using
> 'userRoleName':
>
> This realm configuration would satisfy the new requirements:
> connectionURL="ldap://localhost:389";
> userBase="ou=people,dc=mycompany,dc=com"
>userSearch="(mail={0})"
> userRoleName="memberOf"
> roleBase="ou=groups,dc=mycompany,dc=com"
> roleName="cn"
>roleSearch="(uniqueMember={0})"
> />
>
> I think the last 3 attributes for role are unnecessary, and if so,
> then they're confusing. In my test, which is similar to the LDIF
> right above it:
>
> dn: uid=jjones,ou=people,dc=mycompany,dc=com
> objectClass: inetOrgPerson
> uid: jjones
> sn: jones
> cn: janet jones
> mail: j.jo...@mycompany.com
> memberOf: role2
> memberOf: role3
> userPassword: janet
>
> I didn't need those last 3 role entries and everything worked fine.
You may not need all of the settings. It really depends on the way your LDAP
server is structured. In your particular case you didn't need them. Some
people will though. For an example of when you will need them see the LDIF
used by the documentation.
Dan
> Just a note because this section is already confusing enough and I
> thought that made it worse.
>
> Sorry if I'm wrong in my assumptions.
>
> Thanks-
> Robert
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: jdbc pool: validationQuery vs Connection.isValid
On Wed, Jan 6, 2016 at 10:10 AM, Julian Reschke wrote: > On 2016-01-06 15:21, Christopher Schultz wrote: > >> Julian, >> >> On 1/6/16 7:42 AM, Julian Reschke wrote: >> >>> On 2016-01-06 00:06, Christopher Schultz wrote: >>> Julian, On 1/5/16 9:25 AM, Julian Reschke wrote: > Hi there, > > maybe that's a stupid question, but why do we need a configurable > validationQuery when there's > > Connection.isValid(...) > > < > https://docs.oracle.com/javase/6/docs/api/java/sql/Connection.html#isValid%28int%29 > > > > Because not all JREs have the Connection.isValid method available, and the validation query is a fall-back mechanism. Connection.isValid was added in Java 1.6, and tomcat-pool is backward compatible down to Java 1.5. >>> >>> Ack. >>> >>> So if it wasn't for the required 1.5 compatibility, it could be used the >>> default way to check the connection (still allowing an override, I >>> assume)? >>> >> >> I haven't read the code, so I don't know if tomcat-jdbc will prefer >> Connection.isValid over an explicit validationQuery. My wild guess is >> > > I'm looking at the source in trunk, and it doesn't seem to call isValid() > ever. Are we talking about different things? > If you want to use Connection.isValid(), you could just make a simple custom Validator. It's a dead simple interface to implement. http://svn.apache.org/viewvc/tomcat/tc8.0.x/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/Validator.java?view=markup You can then use the "validatorClassName" attribute on the pool to use the custom validator instead of a validation query. "(String) The name of a class which implements the org.apache.tomcat.jdbc.pool.Validator interface and provides a no-arg constructor (may be implicit). If specified, the class will be used to create a Validator instance which is then used instead of any validation query to validate connections. The default value is null. An example value is com.mycompany.project.SimpleValidator." Dan
Re: [jdbc-pool] Exception while using DisposableConnectionFacade interceptor
On Nov 12, 2013, at 4:39 AM, Isuruwan Herath wrote: > Hi Devs, > > We are using tomcat jdbc-pool v7.0.28. In one of the development > environments we have been intermittently getting an exception from above > interceptor. > > --- > > Caused by: java.sql.SQLException: PooledConnection has already been closed. This typically happens when a database connection is closed outside of the resource pool. For example, if the connection is closed by a firewall or the remote database. Usually adding a validation query is enough to filter out the bad connections, but in some case you'll need to adjust the validationInterval setting as well. See the config docs here. https://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html >at > org.apache.tomcat.jdbc.pool.DisposableConnectionFacade.invoke(DisposableConnectionFacade.java:69) >at $Proxy14.prepareStatement(Unknown Source) >at > org.wso2.carbon.dataservices.core.description.query.SQLQuery.createProcessedPreparedStatement(SQLQuery.java:1367) > > --- > > We are not using a very high volume and we have not set pool properties to > values other than the defaults. It is really difficult to recreate this and > I have tried running the unit tests with different numbers to pool > configurations, but no success in reproducing above. > > IIUC, this occurs when connection is shared in a multi-threaded scenario. > Possibly, one is trying to do some operation while other trying to close it > and return to the pool. You shouldn't have two threads using the same connection from the pool. That would be an error in your program. Each thread should get it's own connection from the pool. In general the pattern used by your code should be something like this. - Get connection from pool - Perform work - Return connection to pool You should hold the connection for a little time as possible, you should make sure you use a proper try..catch..finally block and you should never store or share a connection that you take from the pool. > Has there been any major concurrency related > improvements done after v7.0.28? You can check the change logs to see what has been updated since 7.0.28. Look at the section titled "jdbc-pool", which lists changes made to the pool. https://tomcat.apache.org/tomcat-7.0-doc/changelog.html Dan > > Really appreciate if you could give any sort of input on the cause of the > above. > > Thanks and Regards! > Isuruwan > > > -- > Isuruwan Herath > Technical Lead > > Contact: +94 776 273 296 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: New JDBC SessionManager for non sticky-sessions
On Dec 10, 2013, at 6:34 AM, "Spielmann, Simon" wrote: > Hello together, > > we developed a custom JDBC SessionManager which supports non sticky-sessions. > Is there interest in including this in the official tomcat distribution? Can you tell us more? Some questions coming to mind… - What motivated you to develop this? - How does it work? How does it integrate with Tomcat? - Have you performance / load tested it? If so, with what results? - What databases does it support? What tables does it need setup to work? - What benefits does it offer other than not requiring sticky sessions? or is that the main feature? - Can I use it with sticky sessions or would that break it / defeat the purpose? - How is it different than using a persistent manager with JDBC based store? https://tomcat.apache.org/tomcat-7.0-doc/config/manager.html#Nested_Components - Is the source posted some where? So anyone curious could try it out? - Are there installation instructions? Dan > > Kind Regards > Simon - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: New JDBC SessionManager for non sticky-sessions
On Dec 10, 2013, at 9:00 AM, "Spielmann, Simon" wrote: > The main difference is, that session data is written to the database at the > end of every request. > The existing jdbc session manager does only support "lazy" writes into the > database, so if the app server crashes session data is not guaranteed written > to the database. > We did some load testing, but compared it only to a "in application session > persistence", which does in fact the same but did not reside in tomcat. > We tested it with oracle rac, other database should be possible. > Main feature is the support for sticky seasons and higher availability, > because sessions are in the database after every request (see above). > We have documented installation procedure (in German at the moment). > Translation to English would be possible. > Code is not public available at the moment. I could probably publish it when > general interest is there. If it's not too much trouble, could you share the code and docs? I'm interested enough to at least take a further look and give it a test run, assuming it's using the Apache license. Dan > > Simon > > -Original Message- > From: Daniel Mikusa [mailto:dmik...@gopivotal.com] > Sent: Dienstag, 10. Dezember 2013 14:19 > To: Tomcat Developers List > Subject: Re: New JDBC SessionManager for non sticky-sessions > > On Dec 10, 2013, at 6:34 AM, "Spielmann, Simon" > wrote: > >> Hello together, >> >> we developed a custom JDBC SessionManager which supports non sticky-sessions. >> Is there interest in including this in the official tomcat distribution? > > Can you tell us more? Some questions coming to mind… > > - What motivated you to develop this? > - How does it work? How does it integrate with Tomcat? > - Have you performance / load tested it? If so, with what results? > - What databases does it support? What tables does it need setup to work? > - What benefits does it offer other than not requiring sticky sessions? or > is that the main feature? > - Can I use it with sticky sessions or would that break it / defeat the > purpose? > - How is it different than using a persistent manager with JDBC based store? > > > https://tomcat.apache.org/tomcat-7.0-doc/config/manager.html#Nested_Components > > - Is the source posted some where? So anyone curious could try it out? > - Are there installation instructions? > > Dan > > >> >> Kind Regards >> Simon > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.0.0-RC7
On Dec 11, 2013, at 6:24 PM, Mark Thomas wrote: > The proposed Apache Tomcat 8.0.0 release candidate 7 is now available > for voting. > > Given this is a release candidate I am working on the basis that it is > equivalent to an alpha. The main changes since RC5 are: > - Better handling of generic types in the WebSocket 1.0 implementation > - Refactor resource handling for the class loader > - Add Cobertura support to the unit tests > - Remove anti-Jar locking feature and replace it with open stream > tracking > - Update to Commons Pool 2.0 release > - Complete refactoring of TLD handling including caching of parsed TLDs > - More consistent handling of XML validation options > - Much more detailed visibility of DBCP connections pools in JMX > - Better organisation of JMX beans in the default JConsole view > - Numerous bug fixes > > It can be obtained from: > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.0.0-RC7/ > The Maven staging repo is: > https://repository.apache.org/content/repositories/orgapachetomcat-047/ > The svn tag is: > http://svn.apache.org/repos/asf/tomcat/tags/TOMCAT_8_0_0_RC6/ > > The proposed 8.0.0-RC7 release is: > [ ] Broken - do not release > [X] Alpha - go ahead and release as 8.0.0-RC7 alpha Ran some basic tests with non-blocking io, web sockets and EL 3.0. All worked fine. Dan > > Cheers, > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.0.0-RC8
On Dec 17, 2013, at 6:32 AM, Mark Thomas wrote: > The proposed Apache Tomcat 8.0.0 release candidate 8 is now available > for voting. > > Given this is a release candidate I am working on the basis that it is > equivalent to an alpha. The main changes since RC5 are: > - Better handling of generic types in the WebSocket 1.0 implementation > - Refactor resource handling for the class loader > - Add Cobertura support to the unit tests > - Remove anti-Jar locking feature and replace it with open stream > tracking > - Update to a post Commons Pool 2.0 release snapshot > - Complete refactoring of TLD handling including caching of parsed TLDs > - More consistent handling of XML validation options > - Much more detailed visibility of DBCP connections pools in JMX > - Better organisation of JMX beans in the default JConsole view > - Performance improvements > - Numerous bug fixes > > It can be obtained from: > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.0.0-RC8/ > The Maven staging repo is: > https://repository.apache.org/content/repositories/orgapachetomcat-052/ > The svn tag is: > http://svn.apache.org/repos/asf/tomcat/tags/TOMCAT_8_0_0_RC8/ > > The proposed 8.0.0-RC8 release is: > [ ] Broken - do not release > [ ] Alpha - go ahead and release as 8.0.0-RC8 alpha > > Cheers, > > Mark I'm seeing the following error when running with a security manager enabled. $ cat logs/catalina.out java.lang.ClassNotFoundException: org.apache.tomcat.util.net.AbstractEndpoint$PrivilegedSetTccl at java.net.URLClassLoader$1.run(URLClassLoader.java:366) at java.net.URLClassLoader$1.run(URLClassLoader.java:355) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:354) at java.lang.ClassLoader.loadClass(ClassLoader.java:425) at java.lang.ClassLoader.loadClass(ClassLoader.java:358) at org.apache.catalina.security.SecurityClassLoad.loadTomcatPackage(SecurityClassLoad.java:283) at org.apache.catalina.security.SecurityClassLoad.securityClassLoad(SecurityClassLoad.java:49) at org.apache.catalina.startup.Bootstrap.init(Bootstrap.java:261) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:456) Steps to reproduce: 1.) Download and unzip. 2.) ./bin/startup.sh -security 3.) cat logs/catalina.out Dan > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.0.0-RC9
On Dec 17, 2013, at 7:59 PM, Mark Thomas wrote: > The proposed Apache Tomcat 8.0.0 release candidate 9 is now available > for voting. > > Given this is a release candidate I am working on the basis that it is > equivalent to an alpha. The main changes since RC5 are: > - Better handling of generic types in the WebSocket 1.0 implementation > - Refactor resource handling for the class loader > - Add Cobertura support to the unit tests > - Remove anti-Jar locking feature and replace it with open stream > tracking > - Update to a post Commons Pool 2.0 release snapshot > - Complete refactoring of TLD handling including caching of parsed TLDs > - More consistent handling of XML validation options > - Much more detailed visibility of DBCP connections pools in JMX > - Better organisation of JMX beans in the default JConsole view > - Performance improvements > - Numerous bug fixes > > It can be obtained from: > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.0.0-RC9/ > The Maven staging repo is: > https://repository.apache.org/content/repositories/orgapachetomcat-063/ > The svn tag is: > http://svn.apache.org/repos/asf/tomcat/tags/TOMCAT_8_0_0_RC9/ > > The proposed 8.0.0-RC9 release is: > [ ] Broken - do not release > [X] Alpha - go ahead and release as 8.0.0-RC9 alpha Dan > > Cheers, > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Encoding request URI
On Thu, Sep 4, 2014 at 2:00 AM, Lulseged Zerfu wrote: > Hi > Hope it will format this time. > I am not using any web browser to execute requests. I do use latest http > client component from apache. > My request URI contains characters that are not allowed in a URI. Some > examples are[]"space .etc > If they are not allowed then you must url encode them. http://tools.ietf.org/html/rfc3986#section-2.1 I believe commons HTTP client can help with this. > Therefore I send UTF-8 encoded request URI and it fails. As it should. UTF-8 is not going to help here, it has a different purpose. Dan > But if I ONLY encode not allowed characters, it works fine. > Then I have to decode when processing the request inside a servlet. > The problem with this approach is that I only encode some characters. This > will not work one day I get another unallowed character that's not on my > list. > My request looks like: > /mtasxdms/ > simservs.ngn.etsi.org/users/sip:a...@vodafon.com/simservs.xml/~~/simservs/communication-diversion/NoReplyTimer/simservs/communication-diversion/cp:ruleset/cp:rule[@id="cfnrc"]/cp:conditions/mmt-serv:valid-periods/mmt-serv:valid-days/mmt-serv:day?xmlns(cp=urn:ietf:params:xml:ns:common-policy) > xmlns(mmt-serv=http://schemas.vodafon.com/mmtel/services) > > BRLulseged > > > Date: Wed, 3 Sep 2014 10:09:48 +0100 > > From: ma...@apache.org > > To: dev@tomcat.apache.org > > Subject: Re: Encoding request URI > > > > On 03/09/2014 10:03, Lulseged Zerfu wrote: > > > Hi > > > I have a problem sending UTF-8 encoded request URI to tomcat. I am > always getting Bad request from tomcat. > > > Charset is set to UTF-8 in the request. My connectors in server.xml > have URIEncoding="UTF-8" set. > > > I am using tomcat 8.0.11 on windows x64. > > > I would appreciate any help. > > > > Read this: > > http://www.catb.org/esr/faqs/smart-questions.html > > > > Then post to the users mailing list. > > > > Mark > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: dev-h...@tomcat.apache.org > > >
Re: Tomcat 8 Documentation JNDI Datasource Howto
On Mon, Jul 14, 2014 at 2:10 PM, Andrew Carr wrote: > Hi, > > On this page > http://tomcat.apache.org/tomcat-8.0-doc/jndi-datasource-examples-howto.html > there is an example of a global JDBC resource being defined. There is also > a comment saying "This author has not had success here, although others > have reported so. Clarification would be appreciated here." > Not sure about the why behind this comment, maybe someone else can comment on the comment :) You should be able to define global resources though. If global resources don't work for you then it probably due to a configuration error. Most often, people forget to add resource links. > > I defined the global postgres jdbc definition, and then I add a resource > link in the two web application contexts that I wanted to use the > datasource with, and this resolved the issue. > Sounds right. > > If I did not define the resource links in the context elements I would > receive an error that the driver was not present. > That's correct. A global resource is not exposed to any applications by default. You need to define resource links to indicate which applications can see a given global resource. > > Is this the correct approach to solving this problem? It's one correct way. You can also just define a Resource tag directly in your context. See here. http://tomcat.apache.org/tomcat-8.0-doc/config/context.html#Resource_Definitions The difference being a global resource can be shared across multiple applications, while a resource defined directly in the context (even in conf/context.xml) is specific to that application. > If so, should I > document it this way? Basically: > > 1. Define the global JDBC resource > 2. Define the resource references in the contexts you would like to share > the datasource with. > Does this documentation link help to clarify? http://tomcat.apache.org/tomcat-8.0-doc/jndi-resources-howto.html#Global_configuration If not and you feel there's room for improvement, I think the general suggestion is that patches are welcome. Dan
Re: Java 7 support on Tomcat 5.5
On Apr 1, 2013, at 4:44 PM, Satheesh Babu wrote: > Good Evening! > > We're running our production applications in Tomcat 5.5/JRE 1.5, and there is > a need for us to migrate our applications to Java 7(JRE 1.7). There is no > information available either on java or on Apace Tomcat site regrading the > compatibility of java 7 with tomcat 5.5. Could you please let me know the > compatibility of Java 7/Tomcat 5.5 (or) do we need to upgrade tomcat to 6 > (or) 7, for java 7. You should really consider upgrading to Tomcat 7 or at least Tomcat 6. Tomcat 5.5 is very old and has reached it's end-of-life. http://markmail.org/message/ksvarswxy6t54zcz?q=list:org%2Eapache%2Etomcat%2Eannounce/+5%2E5 Dan > > I truly appreciate your response, thanks for your timely help. > > Thanks, > Satheesh Babu - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.0.0-RC4
On Oct 15, 2013, at 8:48 AM, Mark Thomas wrote:
> The proposed Apache Tomcat 8.0.0 release candidate 4 is now available
> for voting.
>
> Given this is a release candidate I am working on the basis that it is
> equivalent to an alpha. The main changes since RC3 are:
> - Stability fixes in the APR/native connector
> - Stability fixes for non-blocking IO and WebSocket
> - Improvements to unit tests to reduce incidence of false reports
> - Add a drawing board example to the WebSocket examples
> - A handful of bug fixes
> - A small number of enhancements including direct gzip support in the
> default Servlet
> - More HTML clean-up
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.0.0-RC4/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-176/
> The svn tag is:
> http://svn.apache.org/repos/asf/tomcat/tags/TOMCAT_8_0_0_RC4/
>
> The proposed 8.0.0-RC4 release is:
> [ ] Broken - do not release
> [ ] Alpha - go ahead and release as 8.0.0-RC4 alpha
>
> Cheers,
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
Tested a couple apps that I have and everything worked OK for me. One note
though, there are some errors with the examples when I run with the security
manager enabled.
Here are the steps to replicate the issues:
1.) Downloaded Tomcat 8.0.0-RC4 and unzip.
2.) Run "./bin/catalina.sh start -security".
Here are the errors:
1.) On startup, you'll see this error. Adding the permission that is listed in
the stack trace allows the server to start without any errors.
15-Oct-2013 10:05:18.699 SEVERE [localhost-startStop-1]
org.apache.catalina.core.ContainerBase.addChildInternal ContainerBase.addChild:
start:
org.apache.catalina.LifecycleException: Failed to start component
[StandardEngine[Catalina].StandardHost[localhost].StandardContext[/examples]]
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:154)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:726)
at
org.apache.catalina.core.ContainerBase.access$000(ContainerBase.java:130)
at
org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:152)
at
org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:142)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:700)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:698)
at
org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1119)
at
org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig.java:1760)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
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:724)
Caused by: java.security.AccessControlException: access denied
("java.lang.RuntimePermission"
"accessClassInPackage.org.apache.tomcat.websocket.server")
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:372)
at
java.security.AccessController.checkPermission(AccessController.java:559)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at
java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1529)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:305)
at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:190)
at
javax.websocket.server.ServerEndpointConfig$Configurator.loadDefault(ServerEndpointConfig.java:174)
at
javax.websocket.server.ServerEndpointConfig$Configurator.fetchContainerDefaultConfigurator(ServerEndpointConfig.java:151)
at
javax.websocket.server.ServerEndpointConfig$Builder.(ServerEndpointConfig.java:68)
at
javax.websocket.server.ServerEndpointConfig$Builder.create(ServerEndpointConfig.java:56)
at websocket.ExamplesConfig.getEndpointConfigs(ExamplesConfig.java:38)
at org.apache.tomcat.websocket.server.WsSci.onStartup(WsSci.java:99)
at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5265)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
... 14 more
2.) After resolving #1, you'll see this error when you access one of the web
socket examples and the example
