Accessing ServletContext from WebSocket endpoint
Hi, is there a standard way to access ServletContext from a WebSocket ServerEndpoint ? thank you Tomcat is great Enrico Olivelli - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Accessing ServletContext from WebSocket endpoint
I'm trying the example from Tyrus, hoping that it could work on tomcat
https://tyrus.java.net/documentation/1.3/index/deployment.html
this is the simplest code to put ServletContext in userproperties
@WebListener
public class MyWebSocket implements ServletContextListener {
@Override
public void contextInitialized(ServletContextEvent
servletContextEvent) {
final ServerContainer serverContainer = (ServerContainer)
servletContextEvent.getServletContext()
.getAttribute(javax.websocket.server.ServerContainer);
try {
ServerEndpointConfig c =
ServerEndpointConfig.Builder.create(MyWebSocket.class, /endpoint).build();
c.getUserProperties().put(servletContext,
servletContextEvent.getServletContext());
serverContainer.addEndpoint(c);
} catch (DeploymentException e) {
e.printStackTrace();
}
}
@OnOpen
public void onOpen(Session session, EndpointConfig config) {
try {
session.getBasicRemote().sendText(hello +
config.getUserProperties());
} catch (IOException e) {
e.printStackTrace();
}
}
@Override
public void contextDestroyed(ServletContextEvent servletContextEvent) {
}
}
unfortunately I got this exception onOpen
java.lang.NullPointerException
at
org.apache.tomcat.websocket.pojo.PojoEndpointBase.doOnOpen(PojoEndpointBase.java:56)
at
org.apache.tomcat.websocket.pojo.PojoEndpointServer.onOpen(PojoEndpointServer.java:70)
at
org.apache.tomcat.websocket.server.WsHttpUpgradeHandler.init(WsHttpUpgradeHandler.java:129)
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:629)
at
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
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)
Thanks
Enrico
Il 07/12/2013 15:33, Christopher Schultz ha scritto:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Johan,
On 12/7/13, 4:30 AM, Johan Compagner wrote:
On 7 December 2013 04:48, Christopher Schultz
ch...@christopherschultz.netwrote:
because i only see currently api to get the HttpSession and
then through that the ServletContext, problem is that there is
no http session..
Aah... if there is no session, getHttpSession doesn't
automatically create one(). Boo.
and can it create one?
if a browser does a ws: request that will be first just a http
request i guess that is then upgraded But in that first request
can cookies be send over? Because if a websocket creates a http
session then a jsessionid cookie must be set in the browser over
the websocket request. And that jsession cookie must then be used
by also normal http request a browser does to that server..
I'm no WebSocket expert, but the server has to first handle the
request as HTTP, and then upgrade it to WebSocket. The client can
establish a session first, then switch over to WebSocket and inherit
the session. I'm not sure if a pure WebSocket request can create a
session, since WebSocket is /not/ HTTP and therefore cookies are a bit
meaningless.
problem is that i don't want to create a session, i just want to
ServletContext to read some files.
Yup, I get it.
So something like:
EndpointConfig.getUserProperties().put(ServletContext,request.get
Context());
That context can then just return an object which i need to cast
and is then up to the container to provide.
I would lobby to have the container put the ServletContext into the
user properties -- just as you have above -- automatically during
connection set-up. There's nothing stopping Tomcat from doing that
right now, except that it would technically violate the spec and
introduce a non-standard vendor extension.
In this case, it's pretty clear that there is a quite desirable
feature missing from the spec and I think it might be reasonable to
violate it in this instance. I'd prefer to get Mark or Konstantin to
weigh-in on such a step, because it might set a bad precedent for Tomcat.
I'm certainly not going to commit that myself. :)
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJSozG4AAoJEBzwKT+lPKRYwHUP/1/rTzHMuYnG0PydbKAffDOo
5D+/YABdkxvmAs49MhVJyAFs9QLZn3NNmuNLoLnxirkAx2lG1RHxOrnS2VdHWrgE
g5WH5gEoMFyl52rl6QOiaXBFNDfBG7X3kqn8TzUWRMkoxZbwoN5GGG6Uhk3jWv9x
rWw/Bos7DqmssfrT+Y8Uk9+TbegkP0s9r56FY9PUvVPFSqjALX9sFd7WpzEPS8up
NwbAMJpiFydgIwXTmMy69kmTgcvYacfrcbyZuhQmV2PllfKDbNt4THxgop6TXlYp
KrDu3YzINf0DSFUgXNkjz5WGXnstLxjgn943YX54Xy5WBe9zxndOPedMBW/gHGM+
3LdlnPaOM8OGWSu0PZxXXuLIu+oWUcB8oUKaeIMa8Yv1Zb9WIPXe6m3AlAebkfDB
9yDFjcmWS5Fpc/qaXYqrxGMoVZc22GyhijdVn1jd7tK9TJAtGpoMQrQArfcQdJb3
Re: Upgrade fom Tomat 8.0.33 to 8.5.9 - stuck clients
Thank you Chris Il gio 12 gen 2017, 18:04 Christopher Schultz <ch...@christopherschultz.net> ha scritto: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Enrico, > > On 1/12/17 8:53 AM, Enrico Olivelli wrote: > > I'm upgrading from Tomcat 8.0.33. I see that after a period of work > > requests remains "pending", for instance I get all clients > > remaining waiting for a response (parsing HTTP Response header) and > > no active thread on my Tomcat. > > > > This happens in my QA environment where I start several > > WebDriver/Unit tests againts my web application. I have many cases, > > the most simple I this is the following: > > > > on the client side (a JAX-WS client): > > > > "main" #1 prio=5 os_prio=0 tid=0x7f7cf0009000 nid=0x7ddc > > runnable [0x7f7cf6e3f000] > > > > java.lang.Thread.State: RUNNABLE > > > > at java.net.SocketInputStream.socketRead0(Native Method) > > > > at > > java.net.SocketInputStream.socketRead(SocketInputStream.java:116) > > > > at java.net.SocketInputStream.read(SocketInputStream.java:170) > > > > at java.net.SocketInputStream.read(SocketInputStream.java:141) > > > > at java.io.BufferedInputStream.fill(BufferedInputStream.java:246) > > > > at java.io.BufferedInputStream.read1(BufferedInputStream.java:286) > > > > at java.io.BufferedInputStream.read(BufferedInputStream.java:345) > > > > - locked <0xfd159a18> (a java.io.BufferedInputStream) > > > > at > > sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:704) > > Okay, client is waiting. > >From server side application logs I see that the webapp has processed the request. In this case I am using Metro JAX-WS. It seems that the reponse is waiting in some buffer. Is there any way to inspect tomcat buffers? Network buffers? I am using linux. The strange thing is that with Tomcat 8.0.33 there is no problem. The same problem happens even with other servlets of different frameworks and other webapps. On 8.0.x I was using Nio connector, on 8.5 I am using Nio2. The problem is both on http and jsse https. Is any new relevant default value changed from 8.0 and 8.5? I can't find any idea on changelogs or documentation > > in the server side: Full thread dump Java HotSpot(TM) 64-Bit Server > > VM (25.92-b14 mixed mode): > > > > > > "anInnocuousThread" #861 daemon prio=5 os_prio=0 > > tid=0x7ff23c0de800 nid=0xdb26 runnable [0x7ff1ad379000] > > java.lang.Thread.State: RUNNABLE at > > sun.nio.ch.EPoll.epollWait(Native Method) at > > sun.nio.ch.EPollPort$EventHandlerTask.poll(EPollPort.java:194) at > > sun.nio.ch.EPollPort$EventHandlerTask.run(EPollPort.java:268) at > > java.lang.Thread.run(Thread.java:745) at > > sun.misc.InnocuousThread.run(InnocuousThread.java:74) > > > > (lots of this kind) (HTTPS Connector I think) > > Without the rest of the stack trace, it's hard to tell if those are okay > I have cut all the other threads which had the same stacktrace. I have stripped out GC threads, JMX... My application is not present in any thread but I have several clients stuck at waiting for a response. As soon as I can I will attach the full dump Thank you very much I appreciate your help Enrico . > > > "https-jsse-nio2-10.168.10.55-8443-exec-130" #572 daemon prio=5 > > os_prio=0 tid=0x7ff23c0a nid=0xd4a2 waiting on condition > > [0x7ff1b2bbf000] java.lang.Thread.State: WAITING (parking) at > > sun.misc.Unsafe.park(Native Method) - parking to wait for > > <0x80f1d420> (a > > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) > > These > > > are request-processing threads, waiting for work. They are idle. > > > (lots of this kind) (HTTP Connector I think) > > > > "http-nio2-10.168.10.55-8080-exec-21" #281 daemon prio=5 os_prio=0 > > tid=0x7ff2340e7000 nid=0xd262 waiting on condition > > [0x7ff1af995000] java.lang.Thread.State: WAITING (parking) at > > sun.misc.Unsafe.park(Native Method) - parking to wait for > > <0x80f0cdb0> (a > > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) > > Same > > > here. > > The others look okay to me. > > - -chris > -BEGIN PGP SIGNATURE- > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBCAAGBQJYd7cuAAoJEBzwKT+lPKRYjz4QAMdOEYMtJjMP3ZNmwNgUtFiv > EGjupmPN4xYrcqmLGC3uBQUTSPHpwCnSz7rdunqmMsludgKeNdFUrljcWtMjNqHG > Kacv+epNlT60L+Uqfeld4XDiADoXuVfxtX3KwGgN
Upgrade fom Tomat 8.0.33 to 8.5.9 - stuck clients
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) at sun.nio.ch.PendingFuture.get(PendingFuture.java:180) at org.apache.tomcat.util.net.Nio2Endpoint$Acceptor.run(Nio2Endpoint.java:433) at java.lang.Thread.run(Thread.java:745) "ContainerBackgroundProcessor[StandardEngine[Tomcat]]" #83 daemon prio=5 os_prio=0 tid=0x7ff2581ec800 nid=0xd0d6 waiting on condition [0x7ff1b74f3000] java.lang.Thread.State: TIMED_WAITING (sleeping) at java.lang.Thread.sleep(Native Method) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1355) at java.lang.Thread.run(Thread.java:745) "anInnocuousThread" #35 daemon prio=5 os_prio=0 tid=0x7ff25909c800 nid=0xd099 runnable [0x7ff1fc8bd000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.EPoll.epollWait(Native Method) at sun.nio.ch.EPollPort$EventHandlerTask.poll(EPollPort.java:194) at sun.nio.ch.EPollPort$EventHandlerTask.run(EPollPort.java:268) at java.lang.Thread.run(Thread.java:745) at sun.misc.InnocuousThread.run(InnocuousThread.java:74) Thanks Enrico Olivelli
Re: Upgrade fom Tomat 8.0.33 to 8.5.9 - stuck clients
After rolling back to old Nio all clients works very well as expected. I'm sorry, I don't know how to reproduce this kind of issue on a test case, I have tried to write some simple multi-thread tests but I cannot break Tomcat Nio2 connector, it happens only on my QA environment. At this point I'm not able to submit any issue to your bug tracker. Thank you 2017-01-13 0:43 GMT+01:00 Mark Thomas <ma...@apache.org>: > On 12/01/2017 21:09, Enrico Olivelli wrote: > > Thank you Chris > > > > Il gio 12 gen 2017, 18:04 Christopher Schultz < > ch...@christopherschultz.net> > > ha scritto: > > > > Enrico, > > > > On 1/12/17 8:53 AM, Enrico Olivelli wrote: > >>>> I'm upgrading from Tomcat 8.0.33. I see that after a period of work > >>>> requests remains "pending", for instance I get all clients > >>>> remaining waiting for a response (parsing HTTP Response header) and > >>>> no active thread on my Tomcat. > >>>> > >>>> This happens in my QA environment where I start several > >>>> WebDriver/Unit tests againts my web application. I have many cases, > >>>> the most simple I this is the following: > >>>> > >>>> on the client side (a JAX-WS client): > >>>> > >>>> "main" #1 prio=5 os_prio=0 tid=0x7f7cf0009000 nid=0x7ddc > >>>> runnable [0x7f7cf6e3f000] > >>>> > >>>> java.lang.Thread.State: RUNNABLE > >>>> > >>>> at java.net.SocketInputStream.socketRead0(Native Method) > >>>> > >>>> at > >>>> java.net.SocketInputStream.socketRead(SocketInputStream.java:116) > >>>> > >>>> at java.net.SocketInputStream.read(SocketInputStream.java:170) > >>>> > >>>> at java.net.SocketInputStream.read(SocketInputStream.java:141) > >>>> > >>>> at java.io.BufferedInputStream.fill(BufferedInputStream.java:246) > >>>> > >>>> at java.io.BufferedInputStream.read1(BufferedInputStream.java:286) > >>>> > >>>> at java.io.BufferedInputStream.read(BufferedInputStream.java:345) > >>>> > >>>> - locked <0xfd159a18> (a java.io.BufferedInputStream) > >>>> > >>>> at > >>>> sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:704) > > > > Okay, client is waiting. > > > > > >> From server side application logs I see that the webapp has processed > the > >> request. In this case I am using Metro JAX-WS. > >> It seems that the reponse is waiting in some buffer. > >> Is there any way to inspect tomcat buffers? Network buffers? I am using > >> linux. > > > >> The strange thing is that with Tomcat 8.0.33 there is no problem. > >> The same problem happens even with other servlets of different > frameworks > >> and other webapps. > > > >> On 8.0.x I was using Nio connector, on 8.5 I am using Nio2. > >> The problem is both on http and jsse https. > > Try NIO. > > Mark > > > > > >> Is any new relevant default value changed from 8.0 and 8.5? I can't find > >> any idea on changelogs or documentation > > > > > > > > > > > >>>> in the server side: Full thread dump Java HotSpot(TM) 64-Bit Server > >>>> VM (25.92-b14 mixed mode): > >>>> > >>>> > >>>> "anInnocuousThread" #861 daemon prio=5 os_prio=0 > >>>> tid=0x7ff23c0de800 nid=0xdb26 runnable [0x7ff1ad379000] > >>>> java.lang.Thread.State: RUNNABLE at > >>>> sun.nio.ch.EPoll.epollWait(Native Method) at > >>>> sun.nio.ch.EPollPort$EventHandlerTask.poll(EPollPort.java:194) at > >>>> sun.nio.ch.EPollPort$EventHandlerTask.run(EPollPort.java:268) at > >>>> java.lang.Thread.run(Thread.java:745) at > >>>> sun.misc.InnocuousThread.run(InnocuousThread.java:74) > >>>> > >>>> (lots of this kind) (HTTPS Connector I think) > > > > Without the rest of the stack trace, it's hard to tell if those are okay > > > > > >> I have cut all the other threads which had the same stacktrace. > >> I have stripped out GC threads, JMX... > >> My application is not present in any thread but I have several clients > >> stuck at waiting for a response. > > > >> As soon as I can I will attach th
Possible bug with Transfer-Encoding: chunked on Tomcat 8.5.9
Hi, I am upgrading from Tomcat 8.0.33 to 8.5.9. I have the following error during a POST made with Apache-HttpClient 4.3.6 I this this is the bad "POST" FINE Jan 09, 2017 3:45:15 PM org.apache.coyote.http11.Http11InputBuffer parseRequestLine BUONO: Received [POST /majordodo HTTP/1.1 Transfer-Encoding: chunked Content-Type: application/json;charset=utf-8 Host: sviluppo06-cs7.sviluppo.dna:11986 Connection: Keep-Alive User-Agent: Apache-HttpClient/4.3.6 (java 1.5) Accept-Encoding: gzip,deflate Authorization: Basic bWFnbmV3czptYWduZXdz 10b78 ] this is the stack trace of the error: java.io.IOException: Invalid end of line sequence (character other than CR or LF found) at org.apache.coyote.http11.filters.ChunkedInputFilter.throwIOException(ChunkedInputFilter.java:655) at org.apache.coyote.http11.filters.ChunkedInputFilter.parseCRLF(ChunkedInputFilter.java:475) at org.apache.coyote.http11.filters.ChunkedInputFilter.doRead(ChunkedInputFilter.java:262) at org.apache.coyote.http11.Http11InputBuffer.doRead(Http11InputBuffer.java:256) at org.apache.coyote.Request.doRead(Request.java:540) at org.apache.catalina.connector.InputBuffer.realReadBytes(InputBuffer.java:319) at org.apache.catalina.connector.InputBuffer.checkByteBufferEof(InputBuffer.java:627) at org.apache.catalina.connector.InputBuffer.read(InputBuffer.java:342) at org.apache.catalina.connector.CoyoteInputStream.read(CoyoteInputStream.java:183) Is it a client error on 'chunked' encoding format or is there some change on Tomcat code which processes his kind of encoding ? I think that the client is sending a broken request, but before the upgrade I did not get the error, is it possible ? I'm using Nio (not Nio2) http Connector, I'm going to to try Nio2 Thank you Enrico Olivelli .
Re: Possible bug with Transfer-Encoding: chunked on Tomcat 8.5.9
I have found a work-around for my case. The original code of my servlet was like this: ObjectMapper mapper = new ObjectMapper(); // Jackson Mapper mapper.readValue(request.getInputStream(), "utf-8") I have added a buffer to hold all the request: byte[] content = readFully(request.getInputStream()); mapper.readValue(content, "utf-8") Now the error has disappeared. I have not checked the code of Jackson Mapper. Is is possible that the ChunkedInputFilter breaks in case of reading more times after the end of the stream ? (calling ServletInputStream#read more times after -1 marker) Should I file an issue ? I'm really sorry but today I have not time to create a working JUnit testcase to demostrate the issue. I can work on it next days. -- Enrico 2017-01-09 16:31 GMT+01:00 Enrico Olivelli <eolive...@gmail.com>: > Hi, I am upgrading from Tomcat 8.0.33 to 8.5.9. > I have the following error during a POST made with Apache-HttpClient 4.3.6 > > I this this is the bad "POST" > > FINE Jan 09, 2017 3:45:15 PM org.apache.coyote.http11.Http11InputBuffer > parseRequestLine > BUONO: Received [POST /majordodo HTTP/1.1 > Transfer-Encoding: chunked > Content-Type: application/json;charset=utf-8 > Host: sviluppo06-cs7.sviluppo.dna:11986 > Connection: Keep-Alive > User-Agent: Apache-HttpClient/4.3.6 (java 1.5) > Accept-Encoding: gzip,deflate > Authorization: Basic bWFnbmV3czptYWduZXdz > > 10b78 > ] > > > this is the stack trace of the error: > java.io.IOException: Invalid end of line sequence (character other than CR > or LF found) > at org.apache.coyote.http11.filters.ChunkedInputFilter. > throwIOException(ChunkedInputFilter.java:655) > at org.apache.coyote.http11.filters.ChunkedInputFilter. > parseCRLF(ChunkedInputFilter.java:475) > at org.apache.coyote.http11.filters.ChunkedInputFilter. > doRead(ChunkedInputFilter.java:262) > at org.apache.coyote.http11.Http11InputBuffer.doRead( > Http11InputBuffer.java:256) > at org.apache.coyote.Request.doRead(Request.java:540) > at org.apache.catalina.connector.InputBuffer.realReadBytes( > InputBuffer.java:319) > at org.apache.catalina.connector.InputBuffer.checkByteBufferEof( > InputBuffer.java:627) > at org.apache.catalina.connector.InputBuffer.read(InputBuffer. > java:342) > at org.apache.catalina.connector.CoyoteInputStream.read( > CoyoteInputStream.java:183) > > > Is it a client error on 'chunked' encoding format or is there some change > on Tomcat code which processes his kind of encoding ? > > I think that the client is sending a broken request, but before the > upgrade I did not get the error, is it possible ? > > I'm using Nio (not Nio2) http Connector, I'm going to to try Nio2 > > Thank you > Enrico Olivelli > > . >
Trivial DataSource ResourceLink error
Hi,
I'm trying to setup a DataSource configured in GlobalNamingResources in
server.xml.
https://tomcat.apache.org/tomcat-8.5-doc/config/context.html#Resource_Links
in server.xml I have:
In context.xml I have
In web.xml I have
http://java.sun.com/xml/ns/j2ee;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd;
version="2.4">
Dobermon
DB Connection
jdbc/DobermonDatabase
javax.sql.DataSource
Container
My code is:
protected Connection getConnection() throws SQLException, NamingException {
InitialContext ic = new InitialContext();
DataSource ds = (DataSource)
ic.lookup("java:comp/env/jdbc/DobermonDatabase");
return ds.getConnection();
}
I am using Tomcat 8.5.9, I get this error:
java.lang.NullPointerException
at
org.apache.naming.factory.DataSourceLinkFactory.getObjectInstance(DataSourceLinkFactory.java:64)
at
javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:321)
at org.apache.naming.NamingContext.lookup(NamingContext.java:839)
at org.apache.naming.NamingContext.lookup(NamingContext.java:159)
at org.apache.naming.NamingContext.lookup(NamingContext.java:827)
at org.apache.naming.NamingContext.lookup(NamingContext.java:159)
at org.apache.naming.NamingContext.lookup(NamingContext.java:827)
at org.apache.naming.NamingContext.lookup(NamingContext.java:159)
at org.apache.naming.NamingContext.lookup(NamingContext.java:827)
at org.apache.naming.NamingContext.lookup(NamingContext.java:173)
at org.apache.naming.SelectorContext.lookup(SelectorContext.java:163)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
at dobermon.QueryResource.getConnection(QueryResource.java:36)
If I declare the datasource inside context.xml no error is thrown and I get
access the database
I want to use GlobalNamingResources without hardcoding username/password in
context.xml, that is committed to my shared source repository.
Any ideas ?
Is there any trivial error ?
Thank you
-- Enrico
Re: Trivial DataSource ResourceLink error
2017-03-13 12:44 GMT+01:00 Konstantin Kolinko <knst.koli...@gmail.com>:
> 2017-03-13 13:44 GMT+03:00 Enrico Olivelli <eolive...@gmail.com>:
> > Hi,
> > I'm trying to setup a DataSource configured in GlobalNamingResources in
> > server.xml.
> > https://tomcat.apache.org/tomcat-8.5-doc/config/context.
> html#Resource_Links
> >
> > in server.xml I have:
> >
> >
> >
> > > type="org.apache.catalina.UserDatabase"
> > description="User database that can be updated and saved"
> > factory="org.apache.catalina.users.
> MemoryUserDatabaseFactory"
> > pathname="conf/tomcat-users.xml" />
> >
> >> auth="Container"
> > type="javax.sql.DataSource"
> > driverClassName="net.sourceforge.jtds.jdbc.Driver"
> > url="jdbc:jtds:sqlserver://x"
> > username="x"
> > password=""
> > maxTotal="20"
> > validationQuery="select 1"
> > maxIdle="10"
> > maxWaitMillis="-1" />
> >
> >
> >
> > In context.xml I have
>
> Which context.xml file?
> It must be META-INF/context.xml in the webapp or
> conf/// .xml in Tomcat.
>
> A common mistake is to edit the global conf/context.xml file.
>
> >
> >
>
> The "path" attribute is not allowed here. (It is allowed only when
> defining directly in conf/server.xml).
>
it is META-INF/context.xml in the webapp, I cannot remove the 'path'
attribute because without it NetBeans will not deploy the App (this is
surely an issue for NB)
>
> > > name="jdbc/DobermonDatabase"
> > global="jdbc/DobermonDatabase"
> > type="javax.sql.DataSource"
> > factory="org.apache.naming.factory.DataSourceLinkFactory"
> > />
>
> I usually omit the "factory" attribute in a ResourceLink. Setting
> "name", "global" and "type" is enough.
>
by omitting the factory="org.apache.naming.factory.DataSourceLinkFactory"
all works as espected
I wonder if there is a more "portable" way of declaring the resource link
in web.xml without the context.xml file in the web app
But for me at this time the context.xml solution is OK
Thank you very much !
>
> Otherwise it looks good.
>
> >
> >
> >
> > In web.xml I have
> > http://java.sun.com/xml/ns/j2ee;
> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> > xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
> > http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd;
> > version="2.4">
>
> Servlet 2.4 spec, really? You want to stay compatible with Tomcat 5.5?
>
> Note that you can use "validate" function in an XML editor to validate
> this file against its schema (web-app_2_4.xsd).
>
> > Dobermon
> >
> >
> > DB Connection
> > jdbc/DobermonDatabase
> > javax.sql.DataSource
> > Container
> >
> >
> >
> > My code is:
> > protected Connection getConnection() throws SQLException,
> NamingException {
> > InitialContext ic = new InitialContext();
> > DataSource ds = (DataSource)
> > ic.lookup("java:comp/env/jdbc/DobermonDatabase");
> > return ds.getConnection();
> > }
> >
> >
> > I am using Tomcat 8.5.9, I get this error:
> > java.lang.NullPointerException
> > at
> > org.apache.naming.factory.DataSourceLinkFactory.getObjectInstance(
> DataSourceLinkFactory.java:64)
> > at
> > javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:321)
> > at org.apache.naming.NamingContext.lookup(NamingContext.java:839)
> > at org.apache.naming.NamingContext.lookup(NamingContext.java:159)
> > at org.apache.naming.NamingContext.lookup(NamingContext.java:827)
> > at org.apache.naming.NamingContext.lookup(NamingContext.java:159)
> > at org.apache.naming.NamingContext.lookup(NamingContext.java:827)
> > at org.apache.naming.NamingContext.lookup(NamingContext.java:159)
> > at org.apache.naming.NamingContext.lookup(NamingContext.java:827)
> > at org.apache.naming.NamingContext.lookup(NamingContext.java:173)
> > a
Java9 modules and web applications
Hi, I am going to study how to migrate my web applications to java9. I did not find and explicit document on this subject. My first problem is: Web applications are packaged in wars ( or exploded wars), which is the relation with modules? The classes in web-inf/classes and in webinf/lib are considered modules (automatic?) I am using tomcat embedded, I think I will need to use tomcat jars as automatic modules, does anyone already started to deal with this kind of problems? Thanks Enrico -- -- Enrico Olivelli
HttpServletRequest in AsyncContext does not handle X-Forwarded-For (RemoteIpValve)
Hi, I am running a servlet and I get strange result for HttpServletRequest#getRemoteAddr(). I have configured RemoteIpValve which handles the X-Forwarded-For header and replaces the original IP address with the value contains in such header. I have an HttpServlet which dispacts the execution to a custom threadpool and uses request.startAsync() It seems that if I call getRemoteAddr on the original HttpServletRequest the value for getRemoteAddr() is correct, it contains the value of X-Forwarded-For header. When I call getRemoteAddr after calling startAsync() the result is the original IP address of the request. A workaround is to capture the IP Address early but I wonder if I am missing something, if it is an expected behavior or if I should file an issue. I am using tomcat 8.5.15 Thanks Enrico
Re: Mysql vs Postgress
Hi, If you are looking for replication maybe you can out my project, it is HerdDB, you can find it on github or check the website http://herddb.org It has a jdbc driver and natively supports replication, using Apache BookKeeper and Apache Zookeeper. It is 100% free and opensource, ASL v2 licensed. I am an happy user of postgres and mysql and Hbase but HerdDB talks natively SQL like Mysql and PG and it is natively distributed like Hbase. It can run in Embedded mode, so that you do not need an external set of machines. Hope that helps Ping me of you need help or use github issue tracker or subscribe to the mailing list Pg vs mysqlfor complex applications with heavy usage of complex queries PG is surely better from my experience Cheers Enrico Il mer 24 gen 2018, 22:38 Loai Abdallatif <loai.abdalla...@gmail.com> ha scritto: > Dear all > > I have project that is based on Tomcat/apache Servers , any one can help > regarding the best DB engine * mysql or Postgress ) keeping in mind that > I'm interested in DB clustering/Replication feature ? > > Kind Regards, > -- -- Enrico Olivelli
Re: /manager/text/list fails in 9.0.31, works in 9.0.27
I am investingating this issue with NetBeans and Tomcat 9.0.31 https://issues.apache.org/jira/browse/NETBEANS-3917 This problem report MAY be related, NetBeans is not able to list applications or to access the /manager/text API. It works well with 9.0.30. I will be back with news if it is a Tomcat issue or a NetBeans one. >From Tomcat release notes I see nothing about a potential breakage. Using a fresh new untarred Tomcat 9.0.31 does not work. If I remove the "lib" directory and I replace it with the one from Tomcat 9.0.30 all works as expected. Regards Enrico Il giorno gio 27 feb 2020 alle ore 09:07 Mark Thomas ha scritto: > > On 26/02/2020 18:57, Vishal Agrawal wrote: > > Hello, > > > > I have manager endpoint enabled in my tomcat install. > > > > When I list the manager endoing in tomcat 9.0.31, I get a 401 Unauthorized > > error - > > > > curl -u tomcat:secret http://127.0.0.1:8080/manager/text/list > > > > > "http://www.w3.org/TR/html4/strict.dtd;> > > > > > > 401 Unauthorized > > ... > > > > > > > > However, when I call it in tomcat 9.0.27 it works as expected... > > > > curl -u tomcat:secret http://127.0.0.1:8080/manager/text/list in tomcat > > 9.0.27 it works as expected... > > OK - Listed applications for virtual host [localhost] > > /manager:running:0:manager > > > > The password is configured in tomcat-users.xml using the output from > > /opt/tomcat/bin/https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fdigest.sh=E,1,3tDk5vwY_zoM19PIwVKe3fyfwRAXV_7a8MrPXyx5XiQ5db4bmp89IB1v74yX6cNBQO6ob5X1vfgWGe5Fe0T0DHm6eweKRmHiAyvxG_4cIwsd218AJPe3=1 > > -a sha-512 -h org.apache.catalina.realm.MessageDigestCredentialHandler > > secret > > secret:ca858d2d5c3e86702ed03b90b1808205a4dc795330deac90380dd3642bcab92a$1$b5affd62902693d01f95bb8798b9c02982dbe58038d5e5064a77fa8a00951561cf63d5491a33d86fb2bee930335f3e3ceb324a8a8459d2966231392072ff4d82 > > > >> cat /opt/tomcat/conf/tomcat-users.xml > > ... > > > >> password="7244776efd3bbf6f9a56dfdc6443f898d39b13623ea349929ecf66748cde0923$1$22aab528369d6c453adca7e4928fff24f77110d15bd2e9786554c2dcdf628847a88f9a459e8cec0c942545a83156ca737eb0edb700563d00f926cb8f29fc4d73" > > roles="manager-script"/> ... > > > > I compared the conf folders in both 9.0.27 and 9.0.31 and they appear to be > > identical. > > > > Can someone please help me what I may need to configure more? > > I've just tested the latest 9.0.x code and this works as expected for > me. There have been no code changes in this area since 9.0.31. Further, > I don't see anything likely to be relevant in the history between 9.0.27 > and 9.0.31. > > I've tested the "ca858..." and the "72447..." credential string above. > The "ca858..." string works. The "72447..." does not. Not sure what went > wrong but that incorrect credential string is the issue. > > 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
