IcedTeaWeb questions
Jiri Vanek
jvanek at redhat.com
Wed Jun 12 15:31:47 UTC 2019
On 6/10/19 12:19 PM, Vassilis Virvilis wrote:
> Sorry this time with subject
>
> Hi,
>
> I am new to the list. I researched all the questions below to the
> best of my abilities. If this is not the right place for such queries
> I apologize upfront and I would appreciate it if you could point me
> to the right direction.
Thank you for reching ITW. I hope I will explain all your questions
>
> So the webstart is dead for us after java 11 upgrade and I have been
> tasked to research alternatives.
>
> The story so far.
>
> In linux we were already using IcedTea-Web. Nothing to be done here
> webstart wise. Task completed. Great.
TY:)
>
> In Windows I used the AdoptOpenJdk msi installer and the IcedTea-Web
> msi installer. Worked great. Kudos to everybody and big thanks.
Hi! They come from here https://github.com/AdoptOpenJDK/IcedTea-Web/releases/tag/icedtea ?
Interesting, I was not part of the release, which may not meter, but the release missed my Testing.
LAt release Iwas testing was:
http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2019-March/041321.html
This shoould not have any efect, I'm just ensuring what release you are on.
>
> In MacOSX now I was able to make it work with minimal patching on the
> portable build. Various questions were accumulated and I wasn't sure
> if I should spam github. I decided to ask here first.
So shell launchers. Yah:( they are not future complete.
>
> Let me know if you want me to create a github issue for any of this.
>
> 1) In MacOSX someone can use
> JRE=`/usr/libexec/java_home`
> to detect java home. Do you want me to try create a pull request along
> these lines like:
> [ -x /usr/libexec/java_home ] && JRE=`/usr/libexec/java_home`;
In native launchers, PATH is also scanned for possible JRE. Would this solve your issue?
If yes, then I would go with PATH approach.
also JAVA_HOME should bealready working for you, and also you can set JRE in
$CONFIG_HOME/icedtea-web/deployment.properties. Would that work for you?
If not, then your solution may go to play.
>
> 2) Is there any way to have a console with my application's messages
> and exceptions but without all the debug messages of the world? I
> wasn't able to find such a setting.
Console have details button leading to details panel, where you can disable output of itw, and
kepponly output of application.
>
> 3) Having two consoles is annoying (great for debugging) but people
> are not used to it. I found how to turn off the one by specifying
> -Xnofork. Are there are any problems with that approach that
> I should be aware of?
Each ITW have its console. And it have its purpose. The first console can actually have interesting
info.
Firs one belongs to first JVM process, which downloads JNLP, and founds eg XMX in it. Then it knows,
it must spawn new vm, to apply thi setting. Second vm again downloads jnlp and the jars and run app.
Soyou can see, xnofork is disabling some functionality.
Nothing is preventing you from closing the first console, does it?
If you wish to fix it, then likely new deployment property can be introduced, to close the console
of forking VM . Looking forward for PR :)
>
> 4) I tried to give my webstart application another title but in the
> Application Menu just says Boot. That bit was working before. We may
> have apple deprecating features in accordance with Java 9+ changes
> at play here though. Looking around I found:
>
> a) My previous approach. It was working in the past but not
> currently. I will retry to make sure though.
>
> System.setProperty("apple.laf.useScreenMenuBar", "true");
> System.setProperty("com.apple.mrj.application.apple.menu.about.name",
> "MyAppName");
>
> b) -Xdock:name=MyAppName That one works but requires different javaws
> for different jnlp. Furthermore it doesn't play with -Xnofork obviously.
I had never before hear about those two. sorry.
>
> c) java-vm-args attribute in the resource/java jnlp element looks
> like that is not honored, is it? Are there any plans to support
> java-vm-args in the feature?
The title belongs to jnlp's element title. Is it not honored too?
speaking abot java-vm-args, not sure what you are reffering to. -J params are supported.
>
> So what I would like to have:
>
0) find JRE on mac?
..should be answered
> I) Config option to close/hide the first console without resorting
> to -Xnofork
I guess that was answered too.
>
> II) Config option to turn off debugging in the second console while
> keeping the application's messages such as the original netx
> implementation
Also thsi was hopefully answered.
....Oh! now I realised - By console - you mean ITW console or terminal of your OS?
For terminal, ITW should be really silent. Only in --verbose mode it shoudl spawn you with messages.
What bothers you here? Maybe you have debugging proeprty enabled?
As ITW supports headless support, so it supports pipes, if yuo see anything here in non debug mode,
it is bug.
Similarly, I had also wrongly answered your first question. This is your OS behaviour and os setup.
I doubt there is anything we can do around. The second VM is again spawned via javaws.sh. And your
os is opening terminal for each os. Using the javaws binary would solve this, but it means that
somebody have to build native rust launchers on mac. Are yu voulenteer? it would be awesome :)
>
> III) Automatically assign application name via -Xdock:name based
> on the jnlp title in MacOSX or via any other working way possible
> that I currently do not know.
This is first time I hear about -Xdoc. Jnlp's <title> is not what you desire?
You can pass jdk arguments to jvm via javaws -J-Xdoc, but I really do not see -Xdoc in openjdk's
swithces.
>
> Will it help to break them in github issues or is it too much?
Github is nice place to cooperate. We can continue the dsicussion a for a whil ehere, and once we
agree what is bug, what feature, what is PR and what canbe workarounded then move to github.
>
> Thanks again for reading thus far and sorry for the long mail.
>
TYVM for the usage report! It is highly appreciated.
J.
More information about the distro-pkg-dev
mailing list