Re: nginx + Tomcat 9

[Simon De Uvarow]

On Wed, Jul 11, 2018 at 10:41 AM Giacomo Arru - BETA Technologies
 wrote:

> I tried to enable debug logging for org.apache.tomcat.websocket but
> without success
>
> here is my logging.properties
>
>
>
> handlers = java.util.logging.ConsoleHandler
>
> .handlers = 1catalina.org.apache.juli.AsyncFileHandler,
> java.util.logging.ConsoleHandler
>
> java.util.logging.ConsoleHandler.level = ALL
> java.util.logging.ConsoleHandler.formatter =
> org.apache.juli.OneLineFormatter
>
> org.apache.coyote.http2.level = ALL
> org.apache.tomcat.websocket.level = ALL
> org.apache.coyote.http11.Http11AprProtocol = ALL
>
>
>
>
>
> Giacomo
>
>
>
>
>
> Da: "Mark Thomas" 
> A: "users" 
> Inviato: Martedì, 10 luglio 2018 23:27:09
> Oggetto: nginx + Tomcat 9
>
> On 10/07/18 17:59, Giacomo Arru - BETA Technologies wrote:
> > Hi,
> > we are using nginx as proxy for our web app deployed in Tomcat 9.
> >
> > The app uses websocket. The websocket connection dies after 30/40
> seconds and we can't figure out why.
> >
> > Any suggestions?
>
> Turn on debug logging for the org.apache.tomcat.websocket package
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
> --
> Questo messaggio stato analizzato con Libra ESVA ed risultato non infetto.
> Seguire il link qui sotto per segnalarlo come spam:
>


I had a similar problem. I could resolved it by sending a keep alive
message from the browser.
If you still get disconnections (backend or middlerware could disconnect),
you need some logic in the frontend to restart the connection.
I didn't have to change any tomcat configuration, or the websocket code.

You can test connecting direct to tomcat websocket (without nginx) to check
where is the problem.
You can also read these nginx configs:
proxy_connect_timeout
proxy_read_timeout

Hope it helps,


"No olvides, no traiciones, lo que llevas bien dentro de ti. No olvides, no
traiciones, lo que siempre te ha hecho vivir."

Re: A tomcat log output problem

[Simon De Uvarow]

On Mon, Apr 2, 2018 at 9:41 AM 张钧荣 <1024238...@qq.com> wrote:

> Hello !
> My project reported an error related to tomcat logging module. The
> exception information is as follows:
> Apr  2 11:31:27 knowledgebase java: Exception in thread "main"
> java.lang.reflect.InvocationTargetException
> Apr  2 11:31:27 knowledgebase java: Caused by:
> java.lang.ClassNotFoundException:
> org.apache.logging.log4j.core.impl.ThrowableProxy
> Apr  2 11:39:44 knowledgebase java: Exception in thread "Thread-4"
> java.lang.NoClassDefFoundError: org/apache/catalina/Lifecycle$SingleUse
> Apr  2 15:26:49 knowledgebase java: Exception in thread "Thread-4"
> java.lang.NoClassDefFoundError: org/apache/catalina/Lifecycle$SingleUse
> Apr  2 15:55:18 knowledgebase java: Exception in thread "Thread-4"
> java.lang.NoClassDefFoundError: org/apache/catalina/Lifecycle$SingleUse
> Apr  2 16:29:52 knowledgebase java: Exception in thread
> "http-nio-8082-exec-8" java.lang.NoClassDefFoundError:
> org/apache/logging/log4j/core/impl/ThrowableProxy
> Apr  2 16:29:56 knowledgebase java: Exception in thread "Thread-4"
> java.lang.NoClassDefFoundError: org/apache/catalina/Lifecycle$SingleUse
> Apr  2 17:08:29 knowledgebase java: Exception in thread "Thread-4"
> java.lang.NoClassDefFoundError: org/apache/catalina/Lifecycle$SingleUse
> How can I fix it?
>
> Best wishes,
> zjr
>
> 发送自 Windows 10 版邮件应用
>

Hello,
You have to add the missing dependency, either in the tomcat/lib folder or
in the [tomcat/webapps/]/WEB-INF/lib folder.
The missing dependency is the log4j.jar , and it is not part of Tomcat.
It's a library you are using in your app/apps.

Re: asgard tomcat application 404

[Simon De Uvarow]

I don't know about Spring, but according to your exception, and my short
experience, could be a database connection issue.

grails.web.context.GrailsContextLoaderError initializing Grails: Error
creating bean with name 'pluginManager' defined in ServletContext resource
*[/WEB-INF/applicationContext.**xml]*: Invocation of init method failed;
nested exception is java.lang.NullPointerException: Cannot invoke method
getAt() on null object

Usually in the context file is where u define the connection pool, and JPA
stuff.
The null pointer exception makes me imagine that a DB connection, or entity
manager, couldn't be created.

Maybe the asgard database was not created as expected by the app?

Hope it helps,


"No olvides, no traiciones, lo que llevas bien dentro de ti. No olvides, no
traiciones, lo que siempre te ha hecho vivir."

On Tue, Feb 20, 2018 at 12:06 AM, Tim Dunphy  wrote:

> Ok guys. Got it! Thanks for your input. I'll follow up with the Asgard
> list, assuming I can find it.
>
> Thanks
>
> On Fri, Feb 16, 2018 at 2:40 PM, Olaf Kock  wrote:
>
> >
> > On 15.02.2018 23:39, Tim Dunphy wrote:
> >
> >> I'm trying to get Netflix Asgard tomcat app working. I'm using tomcat 9.
> >> I'm using windows.
> >> [...]
> >>
> > Tomcat is about as much involved in this as is Windows. To second
> > Christopher's OT answer: This is a problem of the deployed application,
> not
> > of Tomcat. You should look for help in the Asgard community. Tomcat
> doesn't
> > use spring, thus there's not even common ground.
> >
> > Olaf
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
> >
>
>
> --
> GPG me!!
>
> gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B
>

Re: Monitoring Tomcat JDBC Connection Pool with JConsole?

[Simon De Uvarow]

"No olvides, no traiciones, lo que llevas bien dentro de ti. No olvides, no
traiciones, lo que siempre te ha hecho vivir."

On Thu, Jan 11, 2018 at 6:47 PM, Jerry Malcolm 
wrote:

> I followed the instructions to enable JMX on Tomcat.  I added the
> following lines to java config:
>
> -Dcom.sun.management.jmxremote
> -Dcom.sun.management.jmxremote.port=8083
> -Dcom.sun.management.jmxremote.ssl=false
> -Dcom.sun.management.jmxremote.authenticate=false
> -Djava.rmi.server.hostname=localhost
>
> I opened JConsole localhost;8083, and it connected.   I can see CPU, heap,
> classes, and thread graphs.  When I look at the MBean tab, I see a Catalina
> entry and a "DataSource" entry below that.  Expanding that gives me a ton
> of attributes, operations, and notifications for my various datasources.
> That's fine.  But what I want is to be able to do is monitor a graph of the
> connection pools.  I saw an example graph on a 3rd party web post from
> several years ago.  But I can't find anything that shows connection pool
> usage graphs in my JConsole.
>
> What am I missing?
>
> Thanks.
>
> Jerry
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
Maybe you can try jvisualvm instead of JConsole.
The binary is in the /bin folder of the JAVA_HOME.
You can also add plugins to it. Maybe there is a plugin for your need.

regards,

Re: Tomcat 8.5 justification (UNCLASSIFIED)

[Simon De Uvarow]

Hi, do you want to compare tomcat 8.5.last with what version ?



"No olvides, no traiciones, lo que llevas bien dentro de ti. No olvides, no
traiciones, lo que siempre te ha hecho vivir."

On Thu, Nov 16, 2017 at 8:52 PM, Lueders, Paul T CIV USARMY NGIC (US) <
paul.t.lueders@mail.mil> wrote:

> CLASSIFICATION: UNCLASSIFIED
>
> I have been tasked to migrate our apps to tomcat 8.5.  But first I need to
> convince management that it is a good idea.  Does anyone have any documents
> that state the benefits of using tomcat 8.5?
>
> Thanks a lot,
>
> Paul
> CLASSIFICATION: UNCLASSIFIED
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Tomcat 8.5.16 cuts end of body after 10485761 bytes

[Simon De Uvarow]

Hi,

"No olvides, no traiciones, lo que llevas bien dentro de ti. No olvides, no
traiciones, lo que siempre te ha hecho vivir."

On Tue, Aug 29, 2017 at 11:42 AM, Felix Schumacher <
felix.schumac...@internetallee.de> wrote:

> Am 29.08.2017 um 04:44 schrieb Simon De Uvarow:
>
>> Hi, I have to respond a big json file:
>>
>> return Response.status(Status.OK).entity(new
>> SimpleDataMessageResponse("TASK_FINISH",
>> str)).build();
>>
>> The tomcat logs correctly the size in the access log file:
>>
>> 127.0.0.1 - - [29/Aug/2017:02:26:07 +] "GET /./interactiveTask/
>> 1076dde0-b199-4043-9047-e897050eb7fa HTTP/1.1" 200 *12815716 *748 .
>>
>> *But the browser receives only 10485761 bytes (10 MB).*
>>
>> I tested with Chrome, Firefox and finally with JMeter, and it's the same
>> in
>> all cases:
>> The following is the result of the JMeter:
>>
>> Size in bytes: *12815830*
>> Sent bytes:564
>> Headers size in bytes: 114
>> Body size in bytes: *12815716<- but if I run the JMeter script , copy
>> the response and check the size, it's **10485761 bytes, not 12815716
>> bytes*
>> Data type ("text"|"bin"|""): text
>> Response code: 200
>> Response message:
>>
>> Response headers:
>> HTTP/1.1 200
>> Content-Type: application/json
>> Transfer-Encoding: chunked
>> Date: Tue, 29 Aug 2017 02:26:07 GMT
>>
>> GET http://... /interactiveTask/1076dde0-b199-4043-9047-e897050eb7fa
>>
>> Request Headers:
>> Connection: keep-alive
>> Referer: -
>> Accept-Language: es-ES,es;q=0.8,en;q=0.6,gl;q=0.4,en-US;q=0.2
>> Accept-Encoding: gzip, deflate, br
>> Accept: application/json, text/plain, */*
>> User-Agent: 
>> Host: localhost:8080
>>
>>
>>
>> Any idea of what could be happening ?
>> Is there any max size to configure and fix this?
>>
>
> Well, JMeter has a default max size for storing body contents. It is 10 MB
> and can be configured with a property in bin/jmeter.properties:
>
>
> # Max size of bytes stored in memory per SampleResult
> # Ensure you don't exceed max capacity of a Java Array and remember.
> # that the higher it is, the higher JMeter will consume heap
> # Defaults to 10MB
> #httpsampler.max_bytes_to_store_per_request=10485760
>
> Do you have any other signs for the truncation apart from JMeter? How did
> you measure the size in the browsers?
>
> Regards,
>  Felix
>
>
>> thanks !
>>
>>
>> "No olvides, no traiciones, lo que llevas bien dentro de ti. No olvides,
>> no
>> traiciones, lo que siempre te ha hecho vivir."
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
Ok, thanks, didn't know that JMeter configuration.

I also update the Jersey version to 2.25.1 (I had 2.23.1)

[image: Inline image 1]

Now I see whole content in JMeter. So, looks like the clients (browsers)
are dropping the content.

So, is not a question for this mail list.
Thanks for the help !

Tomcat 8.5.16 cuts end of body after 10485761 bytes

[Simon De Uvarow]

Hi, I have to respond a big json file:

return Response.status(Status.OK).entity(new
SimpleDataMessageResponse("TASK_FINISH",
str)).build();

The tomcat logs correctly the size in the access log file:

127.0.0.1 - - [29/Aug/2017:02:26:07 +] "GET /./interactiveTask/
1076dde0-b199-4043-9047-e897050eb7fa HTTP/1.1" 200 *12815716 *748 .

*But the browser receives only 10485761 bytes (10 MB).*

I tested with Chrome, Firefox and finally with JMeter, and it's the same in
all cases:
The following is the result of the JMeter:

Size in bytes: *12815830*
Sent bytes:564
Headers size in bytes: 114
Body size in bytes: *12815716<- but if I run the JMeter script , copy
the response and check the size, it's **10485761 bytes, not 12815716 bytes*
Data type ("text"|"bin"|""): text
Response code: 200
Response message:

Response headers:
HTTP/1.1 200
Content-Type: application/json
Transfer-Encoding: chunked
Date: Tue, 29 Aug 2017 02:26:07 GMT

GET http://... /interactiveTask/1076dde0-b199-4043-9047-e897050eb7fa

Request Headers:
Connection: keep-alive
Referer: -
Accept-Language: es-ES,es;q=0.8,en;q=0.6,gl;q=0.4,en-US;q=0.2
Accept-Encoding: gzip, deflate, br
Accept: application/json, text/plain, */*
User-Agent: 
Host: localhost:8080



Any idea of what could be happening ?
Is there any max size to configure and fix this?

thanks !


"No olvides, no traiciones, lo que llevas bien dentro de ti. No olvides, no
traiciones, lo que siempre te ha hecho vivir."

Re: Detect client disconnect in Tomcat

[Simon De Uvarow]

"No olvides, no traiciones, lo que llevas bien dentro de ti. No olvides, no
traiciones, lo que siempre te ha hecho vivir."

On Wed, Aug 23, 2017 at 8:33 AM, André Warnier (tomcat) 
wrote:

> On 23.08.2017 09:48, Grigor Aleksanyan wrote:
>
>> Hi Simon,
>>
>> If I understood your approach correctly, then this will work only if I am
>> the one that implements the client, right ? What about cases when client
>> is
>> browser or curl, not my c++ app ?
>>
>
> Yes, that is one of the issues. Most browsers, after they send a request
> to a server, wait for about 3 minutes for an answer (which may be just one
> byte, but "something"). If they do not get the beginning of an answer
> within that timeframe, they will
> - close the connection to the server
> - automatically display some internal error page to the effect that "this
> server is not responding, please repeat your request later"
> The only way to stop this behaviour, at the browser level, is to have some
> "applet" builtin (in your previous application page), which "polls" the
> server regularly, to get some kind of "ack" back, which resets the
> browser's timer.
>
> For expected long-running requests on the server, such a thing is usually
> part of the application, and shows itself in the browser as some kind of
> "progress bar", moving dots etc. That is /also/ a way to avoid that the
> user "panics" at not getting a response right away, and starts clicking
> left and right (which would also cause the browser to close that connection
> without waiting for the response).
>
> All of this, is a legacy from the original design of HTTP, which was
> originally designed for
> - client sends a request to a server, to get back "one thing" (a HTML page
> or a file)
> - the server sends back the requested resource (or an error if it doesn't
> have it)
> and then everyone is finished and the next such transaction is something
> totally disjointed and different.
> Over time, this original design has been "patched" a number of times, to
> accomodate more and more sophisticated interactions, as the WWW has
> "exploded" much beyond the original designers expectations. (And also as
> the capabilities of clients and servers have exploded).
> But one consideration has always been to maintain backward compatibility,
> so there are some basic principles which are difficult to modify, and
> application designers have to cope with them.
> Until someone invents - and manages to get adopted - something radically
> new and different, to replace HTTP. Websockets is a step, but it's still
> somewhat of a patch onto HTTP.
>
>
Yes, you have to implement the "retry/pooling" logic in the client.
Today , browsers running javascript apps make this possible.

The client side is like:

1- POST start big job URL
 response comes with job id

2- while (!end) {
   GET job result URL + job id
response comes with false or with the job result
   if (response comes with false) {
   sleep 10 seconds
   }  else {
   end = true;
   manage result of big job
}
}

That is something you can do with javascript and modern browsers. Search
for AJAX: Async HTTP requests.

Re: Detect client disconnect in Tomcat

[Simon De Uvarow]

"No olvides, no traiciones, lo que llevas bien dentro de ti. No olvides, no
traiciones, lo que siempre te ha hecho vivir."

On Tue, Aug 22, 2017 at 11:36 AM, André Warnier (tomcat) 
wrote:

> On 22.08.2017 10:50, Grigor Aleksanyan wrote:
>
>> Hi,
>>
>> I have a web application (.war file) running under *apache-tomcat-7.0.52*.
>> It is a proxy application between my c++ client and server apps. Once HTTP
>> request (from the client) is received by web application, it propagates
>> request to the server and sends response back to the client once it is
>> ready. Server may need long time before it produces some data to send to
>> the client (also it can send data by chunks with really long delays etc.).
>>
>> My question is.
>>
>> *Is there a way to detect client disconnect before the time server has
>> something ready to be written to the output stream?* In case if server
>> writes something after client's disconnect, obviously I will get an
>> exception and can handle it properly. But my goal is to avoid waiting for
>> the server to produce some data to write, to detect this. I saw a couple
>> of
>> forums and mailing lists where people say that only way to do this, is by
>> writing to outputstream. But in case of websockets I know that I can get
>> notifications that connection was closed by the client.
>>
>> I believe this is a very common issue people face and there should be a
>> graceful solution for this for HTTP as well.
>>
>> Can you please advice ?
>>
>>
> Hi.
> You describe the problem well, and even the solution.
>
> The problem is not at the Tomcat level, nor at the HTTP level. The problem
> is at the lower TCP/IP level, and there is not much that Tomcat or HTTP can
> do about it.
> When a client establishes a TCP connection to a server, this is a
> "virtual" connection. There is no hardware or physical line that is
> dedicated to this connection. In other words, it exists only as long as the
> server and the client agree that it exists.
> (And if there are any firewalls or proxies in-between, it is not even one
> connection, it is multiple chained connections).
>
> If the client just decides to "go away", without explicitly telling the
> server so, the server side is totally unaware that the client has gone,
> until the server tries to send a packet on the connection, and (some time
> after that) expects to receive an "ACK" and does not get one.
> In the case of websocket, you have a well-behaved client, that
> (supposedly) tells the server when it is closing the connection. So the
> application could test this, by sending some kind of "probe" from time to
> time, to check that the client is still there.
> And the client would expect such a probe, and know that it is a probe, and
> that it is not data. So it could just respond with some kind of "ack", that
> the server also would interpret correctly.
> But even then, if the client host were to just crash (or anything
> in-between, like a firewall or a router e.g.) you would have the same issue
> : nothing is sent to the server saying that the connection no longer
> exists, so the server thinks it is still there, as long as it does not send
> anything.
>
> And you are also right to say that it affects a lot of people and their
> applications.
> It is frustrating to e.g. start some long and heavy search in a database,
> and then when the result appears, find out that there is nobody listening
> anymore (*).
> There may be some good universal solutions to this, but so far I don't
> know of any.
> Fame awaits you, if you find one that can be universally applicable.
>
>
> (*) and even if you knew that the client has gone, some tasks which you
> started in the background, may not be so easy to stop in the middle either.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
For cases that could have the described issue (HTTP request that may take
too long), I decided to create the "Interactive Task Manager".
The HTTP request starts a task to process something at server side, and
gets a quick response with the UUID of the task. Then the client can pool
asking if the task has finished.
When the task finishes, it stores the result as JSON in a temporal file.
When the client gets the result, the Interactive Task Manager deletes the
temporal file.
The Interactive Task Manager has it own thread pool to process the tasks.

It adds some overhead: HTTP requests asking for news + storing the result
to file + and reading it back. But it doesn't depend on configuration
changes, or hardware speed. It's robust.

I have the idea that HTTP requests should be resolved quikly (always less
than some seconds). If not, it's a bug, so we need to reimplement the
backend to fix it.

It's one possible solution. Maybe not the best.
Hope it helps.

Re: Source Package file path location in Tomcat

[Simon De Uvarow]

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

Check the left side menu .. you will find downloads for all versions of
Tomcat.
In the download page you can download binary distributions and also source
code.


"No olvides, no traiciones, lo que llevas bien dentro de ti. No olvides, no
traiciones, lo que siempre te ha hecho vivir."

On Tue, May 30, 2017 at 4:40 AM, Shaik, Mohammad N. <
mohammad.n.sh...@accenture.com> wrote:

> Hello,
>
> Can you please help in sharing the Source Package file path location in
> Tomcat 6 and 7 versions?
>
> We need to put the Source Package of Tomcat 7 in Tomcat 6 so that we can
> use the security filters of Tomcat 7 in Tomcat 6.
>
>
> Regards,
> Mohammad Nayeem
>
> 
>
> This message is for the designated recipient only and may contain
> privileged, proprietary, or otherwise confidential information. If you have
> received it in error, please notify the sender immediately and delete the
> original. Any other use of the e-mail by you is prohibited. Where allowed
> by local law, electronic communications with Accenture and its affiliates,
> including e-mail and instant messaging (including content), may be scanned
> by our systems for the purposes of information security and assessment of
> internal compliance with Accenture policy.
> 
> __
>
> www.accenture.com
>

Re: Automatic deploy : java.util.zip.ZipException on macosx

[Simon De Uvarow]

Sorry, the
   "A WAR file may be digitally signed
<https://en.wikipedia.org/wiki/Digital_signature> in the same way as a JAR
<https://en.wikipedia.org/wiki/JAR_%28file_format%29> file in order to
allow others to determine where the source code came from."
 wasn't correct. My bad.

But try searching why your war file doesn't contain the META-INF folder.





"No olvides, no traiciones, lo que llevas bien dentro de ti. No olvides, no
traiciones, lo que siempre te ha hecho vivir."

On Wed, May 24, 2017 at 8:35 AM, Simon De Uvarow 
wrote:

> Hi Ricardo, it looks like your war files doesn't contain the META-INF
> folder.
>
> Check here:
> https://en.wikipedia.org/wiki/WAR_(file_format)
>
> "A WAR file may be digitally signed
> <https://en.wikipedia.org/wiki/Digital_signature> in the same way as a JAR
> <https://en.wikipedia.org/wiki/JAR_%28file_format%29> file in order to
> allow others to determine where the source code came from."
>
> https://en.wikipedia.org/wiki/JAR_(file_format)
>
> Hope it helps,
>
>
> "No olvides, no traiciones, lo que llevas bien dentro de ti. No olvides,
> no traiciones, lo que siempre te ha hecho vivir."
>
> On Wed, May 24, 2017 at 8:31 AM, Riccardo Cohen  > wrote:
>
>> Hello
>>
>> I'm new to tomcat and just tried sucessfully a small hello world with
>> tomcat 8.5.14 on macosx / java 1.8.0_25.
>>
>> With IntelliJ I created a war thanks to their tomcat plugin. The war is
>> valid and can be unzipped with no problem:
>>
>> .../apache-tomcat-8.5.14/webapps> unzip web_war.war
>> Archive:  web_war.war
>>   inflating: Basic1.jsp
>>   inflating: Basic2.jsp
>>   inflating: header.jspf
>>creating: WEB-INF/
>>creating: WEB-INF/classes/
>>creating: WEB-INF/classes/Basic2/
>>   inflating: WEB-INF/classes/Basic2/Basic2Servlet.class
>>   inflating: WEB-INF/web.xml
>>
>> But when I put it in $CATALINA_HOME/webapps , I have an exception a
>> launch time :
>>
>> java.util.zip.ZipException: error in opening zip file
>>
>> (full log below). I found nothing on googling about this error. Where
>> should I search ?
>>
>> Thanks a lot.
>>
>> --
>> Riccardo Cohen
>> +33 6 09 83 64 49 <+33%206%2009%2083%2064%2049>
>> E5Group
>> http://www.5flow.com
>>
>>
>>
>>
>>
>>
>> FULL LOG:
>> -
>> Using CATALINA_BASE:   /Users/rc/zdrop/appdata/tomcat
>> Using CATALINA_HOME:   /Applications/softdev/apache-tomcat-8.5.14
>> Using CATALINA_TMPDIR: /Users/rc/zdrop/appdata/tomcat/temp
>> Using JRE_HOME:/Library/Java/JavaVirtualMachi
>> nes/jdk1.8.0_25.jdk/Contents/Home
>> Using CLASSPATH:   /Applications/softdev/apache-t
>> omcat-8.5.14/bin/bootstrap.jar:/Applications/softdev/apache-
>> tomcat-8.5.14/bin/tomcat-juli.jar
>> 24-May-2017 13:26:38.336 INFO [main] 
>> org.apache.catalina.startup.VersionLoggerListener.log
>> Server version:Apache Tomcat/8.5.14
>> 24-May-2017 13:26:38.338 INFO [main] 
>> org.apache.catalina.startup.VersionLoggerListener.log
>> Server built:  Apr 13 2017 12:55:45 UTC
>> 24-May-2017 13:26:38.338 INFO [main] 
>> org.apache.catalina.startup.VersionLoggerListener.log
>> Server number: 8.5.14.0
>> 24-May-2017 13:26:38.338 INFO [main] 
>> org.apache.catalina.startup.VersionLoggerListener.log
>> OS Name:   Mac OS X
>> 24-May-2017 13:26:38.339 INFO [main] 
>> org.apache.catalina.startup.VersionLoggerListener.log
>> OS Version:10.12.4
>> 24-May-2017 13:26:38.339 INFO [main] 
>> org.apache.catalina.startup.VersionLoggerListener.log
>> Architecture:  x86_64
>> 24-May-2017 13:26:38.339 INFO [main] 
>> org.apache.catalina.startup.VersionLoggerListener.log
>> Java Home: /Library/Java/JavaVirtualMachi
>> nes/jdk1.8.0_25.jdk/Contents/Home/jre
>> 24-May-2017 13:26:38.339 INFO [main] 
>> org.apache.catalina.startup.VersionLoggerListener.log
>> JVM Version:   1.8.0_25-b17
>> 24-May-2017 13:26:38.339 INFO [main] 
>> org.apache.catalina.startup.VersionLoggerListener.log
>> JVM Vendor:Oracle Corporation
>> 24-May-2017 13:26:38.339 INFO [main] 
>> org.apache.catalina.startup.VersionLoggerListener.log
>> CATALINA_BASE: /Users/rc/zdrop/appdata/tomcat
>> 24-May-2017 13:26:38.339 INFO [main] 
>> org.apache.catalina.startup.VersionLoggerListener.log
>> CATALINA_HOME: /Applications/softdev/apache-tomcat-8.5.14
>> 24-May-2017 13:26

Re: Automatic deploy : java.util.zip.ZipException on macosx

[Simon De Uvarow]

Hi Ricardo, it looks like your war files doesn't contain the META-INF
folder.

Check here:
https://en.wikipedia.org/wiki/WAR_(file_format)

"A WAR file may be digitally signed
 in the same way as a JAR
 file in order to
allow others to determine where the source code came from."

https://en.wikipedia.org/wiki/JAR_(file_format)

Hope it helps,


"No olvides, no traiciones, lo que llevas bien dentro de ti. No olvides, no
traiciones, lo que siempre te ha hecho vivir."

On Wed, May 24, 2017 at 8:31 AM, Riccardo Cohen 
wrote:

> Hello
>
> I'm new to tomcat and just tried sucessfully a small hello world with
> tomcat 8.5.14 on macosx / java 1.8.0_25.
>
> With IntelliJ I created a war thanks to their tomcat plugin. The war is
> valid and can be unzipped with no problem:
>
> .../apache-tomcat-8.5.14/webapps> unzip web_war.war
> Archive:  web_war.war
>   inflating: Basic1.jsp
>   inflating: Basic2.jsp
>   inflating: header.jspf
>creating: WEB-INF/
>creating: WEB-INF/classes/
>creating: WEB-INF/classes/Basic2/
>   inflating: WEB-INF/classes/Basic2/Basic2Servlet.class
>   inflating: WEB-INF/web.xml
>
> But when I put it in $CATALINA_HOME/webapps , I have an exception a launch
> time :
>
> java.util.zip.ZipException: error in opening zip file
>
> (full log below). I found nothing on googling about this error. Where
> should I search ?
>
> Thanks a lot.
>
> --
> Riccardo Cohen
> +33 6 09 83 64 49 <+33%206%2009%2083%2064%2049>
> E5Group
> http://www.5flow.com
>
>
>
>
>
>
> FULL LOG:
> -
> Using CATALINA_BASE:   /Users/rc/zdrop/appdata/tomcat
> Using CATALINA_HOME:   /Applications/softdev/apache-tomcat-8.5.14
> Using CATALINA_TMPDIR: /Users/rc/zdrop/appdata/tomcat/temp
> Using JRE_HOME:/Library/Java/JavaVirtualMachines/jdk1.8.0_
> 25.jdk/Contents/Home
> Using CLASSPATH:   /Applications/softdev/apache-
> tomcat-8.5.14/bin/bootstrap.jar:/Applications/softdev/
> apache-tomcat-8.5.14/bin/tomcat-juli.jar
> 24-May-2017 13:26:38.336 INFO [main] 
> org.apache.catalina.startup.VersionLoggerListener.log
> Server version:Apache Tomcat/8.5.14
> 24-May-2017 13:26:38.338 INFO [main] 
> org.apache.catalina.startup.VersionLoggerListener.log
> Server built:  Apr 13 2017 12:55:45 UTC
> 24-May-2017 13:26:38.338 INFO [main] 
> org.apache.catalina.startup.VersionLoggerListener.log
> Server number: 8.5.14.0
> 24-May-2017 13:26:38.338 INFO [main] 
> org.apache.catalina.startup.VersionLoggerListener.log
> OS Name:   Mac OS X
> 24-May-2017 13:26:38.339 INFO [main] 
> org.apache.catalina.startup.VersionLoggerListener.log
> OS Version:10.12.4
> 24-May-2017 13:26:38.339 INFO [main] 
> org.apache.catalina.startup.VersionLoggerListener.log
> Architecture:  x86_64
> 24-May-2017 13:26:38.339 INFO [main] 
> org.apache.catalina.startup.VersionLoggerListener.log
> Java Home: /Library/Java/JavaVirtualMachines/jdk1.8.0_
> 25.jdk/Contents/Home/jre
> 24-May-2017 13:26:38.339 INFO [main] 
> org.apache.catalina.startup.VersionLoggerListener.log
> JVM Version:   1.8.0_25-b17
> 24-May-2017 13:26:38.339 INFO [main] 
> org.apache.catalina.startup.VersionLoggerListener.log
> JVM Vendor:Oracle Corporation
> 24-May-2017 13:26:38.339 INFO [main] 
> org.apache.catalina.startup.VersionLoggerListener.log
> CATALINA_BASE: /Users/rc/zdrop/appdata/tomcat
> 24-May-2017 13:26:38.339 INFO [main] 
> org.apache.catalina.startup.VersionLoggerListener.log
> CATALINA_HOME: /Applications/softdev/apache-tomcat-8.5.14
> 24-May-2017 13:26:38.340 INFO [main] 
> org.apache.catalina.startup.VersionLoggerListener.log
> Command line argument: -Djava.util.logging.config.
> file=/Users/rc/zdrop/appdata/tomcat/conf/logging.properties
> 24-May-2017 13:26:38.340 INFO [main] 
> org.apache.catalina.startup.VersionLoggerListener.log
> Command line argument: -Djava.util.logging.manager=org.apache.juli.
> ClassLoaderLogManager
> 24-May-2017 13:26:38.340 INFO [main] 
> org.apache.catalina.startup.VersionLoggerListener.log
> Command line argument: -Djdk.tls.ephemeralDHKeySize=2048
> 24-May-2017 13:26:38.340 INFO [main] 
> org.apache.catalina.startup.VersionLoggerListener.log
> Command line argument: -Djava.protocol.handler.pkgs=org.apache.catalina.
> webresources
> 24-May-2017 13:26:38.340 INFO [main] 
> org.apache.catalina.startup.VersionLoggerListener.log
> Command line argument: -Dcatalina.base=/Users/rc/zdrop/appdata/tomcat
> 24-May-2017 13:26:38.340 INFO [main] 
> org.apache.catalina.startup.VersionLoggerListener.log
> Command line argument: -Dcatalina.home=/Applications/
> softdev/apache-tomcat-8.5.14
> 24-May-2017 13:26:38.340 INFO [main] 
> org.apache.catalina.startup.VersionLoggerListener.log
> Command line argument: -Djava.io.tmpdir=/Users/rc/
> zdrop/appdata/tomcat/temp
> 24-May-2017 13:26:38.341 INFO [main] org.apache.catalina.core.
> AprLifecycleListener.li

Re: WebSocket - Client doesn't receive server messages

[Simon De Uvarow]

To add some info, I implemented a client for browsers (HTML + javascript
client) and it's working properly. I'm receiving the messages from the
server as expected.
So, the problem is in the JAVA test, not the server.


"No olvides, no traiciones, lo que llevas bien dentro de ti. No olvides, no
traiciones, lo que siempre te ha hecho vivir."

On Mon, May 22, 2017 at 9:52 PM, Simon De Uvarow 
wrote:

> Hi, I'm having a strange issue:
>
> I'm developing a frontend with WebSockets, (my first WebSocket! ). To test
> the code I'm also developing some tests to run in Eclipse.
>
> So, I create a Client in the Test, connect to the server, and want to have
> some communication.
> I added lot of logs to debug the issue:
>
> - *WebsocketClientEndpoint*:33 - Connect to server
> - *WebsocketClientEndpoint*:41 - Before Request: Cookie, JSESSIONID=
> A65A4F5711DC8820C246DDD45A409BFA
> - WebSocketFilter:38 - Filter executing ..
> - *WebsocketClientEndpoint*:64 - opening websocket
> - WebSocketServer:59 - 1 has opened a connection
> - WebSocketServer:64 - clientIP: 127.0.0.1
> - *WebsocketClientEndpoin*t:113 - sendMessage 
> - WebSocketServer:75 - onMessage: .
> - WebSocketServer:117 - Send OK message
>
> At the end, the server sends a response ("OK"), and the client waits for
> the response of the server.
> But the client doesn't receive it, no mater how long I wait.
> I debug the Tomcats code, but couldn't find the issue.
> It's not clear for me the point where the library writes the information
> in the socket.
>
> This is how I send the response from the server:
>
> *WFMWebSocketServer*
>
>   * @OnMessage*
>public void onMessage(String message) {
>   ..
>  // Send OK response
>  try {
> logger.debug("Send OK message");
> *session.getBasicRemote().sendText("OK");*
>  } catch (IOException e) {
> e.printStackTrace();
>  }
>  .
>}
>
> The following is the @OnOpen code:
>
>*@OnOpen*
>public void onOpen(Session session) {
>
>   this.session = session;
>   logger.info(session.getId() + " has opened a connection");
>   final PrincipalWithRemoteAddress pws = ((PrincipalWithRemoteAddress)
> session.getUserPrincipal());
>   remoteAdr = pws == null ? null : pws.getRemoteAdr();
>
>   try {
> * session.getBasicRemote().sendText("OK");*
>   } catch (IOException e) {
>  e.printStackTrace();
>   }
>}
>
> Also the previous "OK" message is not received in the client, I don't see
> the log of it in the console:
>
>
> *WebsocketClientEndpoint*
>@OnMessage
>public void onMessage(String message) {
>   logger.debug("onMessage: " + message);
>
>   if (this.messageHandler != null) {
>  this.messageHandler.handleMessage(message);
>   }
>}
>
>
> Any idea why I am having just like half duplex communication ?
> Or any idea how to debug or analyze the issue in order to fix it?
>
> The version of the libraries and Tomcat I'm using is:
> 8.5.15
>
> Thanks!
>
>
> "No olvides, no traiciones, lo que llevas bien dentro de ti. No olvides,
> no traiciones, lo que siempre te ha hecho vivir."
>

WebSocket - Client doesn't receive server messages

[Simon De Uvarow]

Hi, I'm having a strange issue:

I'm developing a frontend with WebSockets, (my first WebSocket! ). To test
the code I'm also developing some tests to run in Eclipse.

So, I create a Client in the Test, connect to the server, and want to have
some communication.
I added lot of logs to debug the issue:

- *WebsocketClientEndpoint*:33 - Connect to server
- *WebsocketClientEndpoint*:41 - Before Request: Cookie,
JSESSIONID=A65A4F5711DC8820C246DDD45A409BFA
- WebSocketFilter:38 - Filter executing ..
- *WebsocketClientEndpoint*:64 - opening websocket
- WebSocketServer:59 - 1 has opened a connection
- WebSocketServer:64 - clientIP: 127.0.0.1
- *WebsocketClientEndpoin*t:113 - sendMessage 
- WebSocketServer:75 - onMessage: .
- WebSocketServer:117 - Send OK message

At the end, the server sends a response ("OK"), and the client waits for
the response of the server.
But the client doesn't receive it, no mater how long I wait.
I debug the Tomcats code, but couldn't find the issue.
It's not clear for me the point where the library writes the information in
the socket.

This is how I send the response from the server:

*WFMWebSocketServer*

  * @OnMessage*
   public void onMessage(String message) {
  ..
 // Send OK response
 try {
logger.debug("Send OK message");
*session.getBasicRemote().sendText("OK");*
 } catch (IOException e) {
e.printStackTrace();
 }
 .
   }

The following is the @OnOpen code:

   *@OnOpen*
   public void onOpen(Session session) {

  this.session = session;
  logger.info(session.getId() + " has opened a connection");
  final PrincipalWithRemoteAddress pws = ((PrincipalWithRemoteAddress)
session.getUserPrincipal());
  remoteAdr = pws == null ? null : pws.getRemoteAdr();

  try {
* session.getBasicRemote().sendText("OK");*
  } catch (IOException e) {
 e.printStackTrace();
  }
   }

Also the previous "OK" message is not received in the client, I don't see
the log of it in the console:


*WebsocketClientEndpoint*
   @OnMessage
   public void onMessage(String message) {
  logger.debug("onMessage: " + message);

  if (this.messageHandler != null) {
 this.messageHandler.handleMessage(message);
  }
   }


Any idea why I am having just like half duplex communication ?
Or any idea how to debug or analyze the issue in order to fix it?

The version of the libraries and Tomcat I'm using is:
8.5.15

Thanks!


"No olvides, no traiciones, lo que llevas bien dentro de ti. No olvides, no
traiciones, lo que siempre te ha hecho vivir."