Following up, I dug into this a lot today with the debugger and stepping
though the platform startup process. I found that the issue wasn't related
to JavaFX at all but rather a native library I use via SWIG bindings. I'm
exploring a JNA-based solution now for that. Happy to say, that aside,
Maybe remove them from the Tomcat automatic deploy folder, could solve it.
But this is default behavior, should be default behavior on the command
line too.
Gj
On Wed, Oct 30, 2019 at 7:46 PM Don wrote:
> In only happens when run from NetBeans. Command line startup.sh is acting
> normally.
In only happens when run from NetBeans. Command line startup.sh is
acting normally. In addition, if I use Debug instead of Run, the
problem is not apparent.
Don
On 10/30/19 2:38 PM, Geertjan Wielenga wrote:
Best to ask on the Tomcat mailing lists.
Gj
On Wed, Oct 30, 2019 at 7:37 PM Don
Where does it keep track of them? On the production server, they are in
the webapps folder but when this is running, there is nothing in the
local server's webapps folder. Is there any way to NOT keep track of
them and run them when they are not wanted?
Don
On 10/30/19 2:22 PM, Geertjan
So those projects were deployed before to Tomcat and Tomcat keeps tracks of
them and redeploys them when Tomcat restarts.
Find out more about Tomcat here: https://tomcat.apache.org/
Gj
On Wed, Oct 30, 2019 at 6:57 PM Don wrote:
> When I select a project and right-click and select Run, it
When I select a project and right-click and select Run, it prints
init:
deps-module-jar:
deps-ear-jar:
deps-jar:
library-inclusion-in-archive:
library-inclusion-in-manifest:
compile:
compile-jsps:
Starting Tomcat process...
Waiting for Tomcat...
In the Tomcat output window I can see that it is
Thank you, thank you, thank you.
It works.
Now I am back in business.
Gary Greenberg
Staff Software Engineer
Data Product Development, BI-A
E: ggree...@visa.com
M: 650-269-7902
-Original Message-
From: Neil C Smith
Sent: Wednesday, October 30, 2019 10:35 AM
To: Greenberg, Gary
Cc:
On Wed, 30 Oct 2019 at 17:19, Greenberg, Gary wrote:
>
> Unfortunately, per company policy we all have to work on Java 8 and versions
> of Java are downloaded automatically.
> Thus, JDK 8u231 was installed on my machine about a week ago. Before I was
> using JDK 8u221 and did not have this
Unfortunately, per company policy we all have to work on Java 8 and versions of
Java are downloaded automatically.
Thus, JDK 8u231 was installed on my machine about a week ago. Before I was
using JDK 8u221 and did not have this problem.
Shall I downgrade?
BTW, I did go to the Oracle site and
On Wed, 30 Oct 2019 at 09:40, Richard Grin
wrote:
>
> I was not clear enough :
>
> I think that the problem about Java 11.0.5 existed before for other versions
> ** of Java SE **.
Obviously I was not clear enough either! ;-) I'm also talking about
Java SE. The problem affecting NetBeans was
I was not clear enough :
I think that the problem about Java 11.0.5 existed before for other versions **
of Java SE **. (not of NetBeans).
Le 30/10/2019 à 10:31, Neil C Smith a écrit :
On Wed, 30 Oct 2019, 09:16 Richard Grin,
mailto:richard.g...@univ-cotedazur.fr>> wrote:
I think that the
On Wed, 30 Oct 2019, 09:16 Richard Grin,
wrote:
> I think that the problem about Java 11.0.5 existed before for other
> versions.
>
It was introduced in JDK updates in mid-Oct, hence why it wasn't picked up
earlier and the workaround only just made it into 11.2
Best wishes,
Neil
>
I think that the problem about Java 11.0.5 existed before for other versions.
Did you try the workaround given by Lazlo?
Le 30/10/2019 à 00:35, Greenberg, Gary a écrit :
No, I am still running it on Java 8.
C:\Users\ggreenbe>java -version
java version "1.8.0_231"
Java(TM) SE Runtime Environment
On Tue, 29 Oct 2019, 23:36 Greenberg, Gary, wrote:
> No, I am still running it on Java 8.
>
That issue also affects the latest Java 8 release. Same workaround.
Best wishes,
Neil
>
14 matches
Mail list logo
