Weasis 3.5.3 released

[Nicolas Roduit]

Weasis 3.5.3, available for download, contains important changes that require some clarification detailed below. The documentation has been updated, please let me know if it still contains any inconsistencies. See also release notes of 3.5.3 and 3.5.1.

The rationale of Weasis changes

The reasons why Weasis must absolutely evolve are:

• Java Web Start has been removed from Java 11 release. This breaks the web deployment of Weasis. 

• Ends of public Java 8 update from Oracle from April 2019, see this post to understand the OpenJDK situation and the Amazon commitment.

General context

In general, all the changes from JDK 9 seem to be a positive evolution of the Java ecosystem to make it more flexible and scalable. However, some of these changes require significant modifications in Java applications as some APIs are not backward compatible anymore. The multi-release packages (JEP238), introduced in Java 9, allows running an application with different JDK APIs. This feature is crucial to keep the Java slogan "Write once, run anywhere".

We want Weasis to remain open and free of charge. That's why we need to ensure its compliance with royalty-free Java Runtime distributions. The feature differences between free and paid JDK distributions are insignificant since version 11. The main reason for the cost is a personalized support service.

To answer the question: why not switch to an HTML5 viewer?

• because we have accumulated know-how for more than 10 years by building Weasis and dcm4che with Java technology. It is still difficult with web technologies to guarantee a certain perennity of applications without constant updating efforts.

• because we believe that an application such as a DICOM viewer requires particular resources (download and display Gigabytes of data) that can be better served by an operating system than by a web browser whose versions and restrictions make it difficult to guarantee a certain stability in the use of the resources.

• the web apps of the future will certainly be more hybrid (pure web vs native) like the progressive web app or WebAssembly. So that’s why we will continue to work to better separate the APIs and User Interface which are constantly evolving.

Weasis 3.5

This version still provides the weasis-portable distribution and the web distribution used by Java Web Start. However, it is recommended to use the native installers (Windows, Linux, and Mac OS X) which are better integrated into the system and compatible with the new weasis protocol.

With the weasis protocol, the launch of Weasis from a web context is simply done by a URI handler registered by the installer as a replacement for Java Web Start. 

The native installers are built from the new JDK jpackage module (currently openjdk-14+9) that allows you to deploy a native application by associating DICOM files with it. 

Once the version is installed on the system, it can be updated automatically if the launching configuration contains a URL of the server distribution (weasis.war). This allows you to work in the same way as Java Web Start for minor version updates. Only major versions will need to be updated with the native installer.

However, the native installer will deeply change the way of deploying and launching Weasis. The consequences are:

Cons:

• It will be not possible anymore to deploy Weasis automatically from a webpage. Deploying Weasis on many computers will require a deployment strategy (e.g. MSI management with group policy on Windows). This new installation (Java + basic plugins of Weasis) can be compared to the Java installation previously.

• It will require building a package for every system (constraints for the developers and need to have all the operating systems for compilation).

• The native package with Java will be larger than the old one. However, the difference is not really significant.
  
  

Pros:

• Get rid of the Java Webstart security constraints without a clear strategy. Java Webstart was the last piece of software not fully open source used by Weasis.

• The new weasis protocol will start the viewer faster than Java Webstart.

• The new weasis protocol has better control of launch parameters and better manage the single instance mechanism.

• Java Runtime will be embedded with the application. No need to care about the Java version installed on the system. Ensure better compatibility between Java and Weasis.

• Supports HiDPI (High Dots Per Inch) displays (related to new Java releases).

• The native installer will better manage to register the URI scheme (weasis://...) for each system than Java Webstart did. This allows launching Weasis from most of the browsers or any other applications.

• The package is installed at a system level (available for all the users of a machine).

• It will solve security problems (sandboxing)  and provide better integration with Mac OS X.

[Kirill K]

So, to integrate with arc-light we will need to install weasis twice? First as package on all PCs, then all the pacs-connector +war stuff on server?

понедельник, 12 августа 2019 г., 10:03:42 UTC+3 пользователь Nicolas Roduit написал:

[Nicolas Roduit]

As specified in the documentation, the server-side version is not required. However, the server-side version automatically updates all client workstations (as with Java Webstart). For example, it will be possible to deploy weasis.war (version 3.5.4) so that all the client workstations can be updated without intervention.

The installation on the client workstations must be done at least once and then during the major versions for Java and weasis launcher evolutions.

Le lundi 12 août 2019 13:55:30 UTC+2, Kirill K a écrit :
> So, to integrate with arc-light we will need to install weasis twice? First as package on all PCs, then all the pacs-connector +war stuff on server?
>
> понедельник, 12 августа 2019 г., 10:03:42 UTC+3 пользователь Nicolas Roduit написал:
>

> Weasis 3.5.3, available for download, contains important changes that require some clarification detailed below. The documentation has been updated, please let me know if it still contains any inconsistencies. See also release notes of 3.5.3 and 3.5.1.The rationale of Weasis changes

> The reasons why Weasis must absolutely evolve are:
> Java Web Start has been removed from Java 11 release. This breaks the web deployment of Weasis. 

> Ends of public Java 8 update from Oracle from April 2019, see this post to understand the OpenJDK situation and the Amazon commitment.General context

> In general, all the changes from JDK 9 seem to be a positive evolution of the Java ecosystem to make it more flexible and scalable. However, some of these changes require significant modifications in Java applications as some APIs are not backward compatible anymore. The multi-release packages (JEP238), introduced in Java 9, allows running an application with different JDK APIs. This feature is crucial to keep the Java slogan "Write once, run anywhere".
>
> We want Weasis to remain open and free of charge. That's why we need to ensure its compliance with royalty-free Java Runtime distributions. The feature differences between free and paid JDK distributions are insignificant since version 11. The main reason for the cost is a personalized support service.
>
> To answer the question: why not switch to an HTML5 viewer?
> because we have accumulated know-how for more than 10 years by building Weasis and dcm4che with Java technology. It is still difficult with web technologies to guarantee a certain perennity of applications without constant updating efforts.
> because we believe that an application such as a DICOM viewer requires particular resources (download and display Gigabytes of data) that can be better served by an operating system than by a web browser whose versions and restrictions make it difficult to guarantee a certain stability in the use of the resources.

> the web apps of the future will certainly be more hybrid (pure web vs native) like the progressive web app or WebAssembly. So that’s why we will continue to work to better separate the APIs and User Interface which are constantly evolving.Weasis 3.5

[Marcel Nóbrega]

Just asked about the dicomizer fraturei, bit nevermind, Just found the Paths on program files. Thanks

[Rana Asim Wajid]

So basically the end of Weasis as a web app as we know it....sad day

[Nicolas Roduit]

I don't think we should be nostalgic because the evolutions allow us to look to the future in a more open and controlled way by abandoning the proprietary Java Webstart technology.

The change is not so important considering that the native installer replaces the Java installation previously. The weasis protocol allows more flexibility by directly launching the application with a configuration in the URL and as with Java Webstart, the Weasis modules can be updated by the server-side distribution.

In addition, in the next version, it should be possible to more easily configure archives or PACS with DICOMWeb services; this without the need to install weasis-pacs-connector but by passing directly in the URL the necessary parameters for Weasis to use the QIDO/WADO-RS.

[Gadi Levy]

In the old method there was a way to include the xml manifest inside the jnlp file (gzip and b64 encoded) with this statement: <argument>$dicom:get -i "<encoded xml here>"</argument>.
Is there a similar way in the new method ? Does the $dicom:get -i  command still exists ?

Thanks

[Nicolas Roduit]

Yes, the command still exists. It should work but I haven't tried. You need to build the URL, the value can be injected after the URL encoding as the content is in base64. 

[Gadi Levy]

Thank you Nicolas, I can confirm that the -i flag works as expected. However there is a url length limit imposed by the browsers. 

1. Is this length limitation also valid for the weasis:// scheme ?

2. installing on Windows causes a system security warning: 

Windows protected your PC

Windows Defender SmartScreen prevented an unrecognized app from starting. Running this app might put your PC at risk.

App: Weasis-3.5.3-x86-64.msi 

Publisher: Unknown publisher.

The user must click more information and then install anyway to proceed.

I believe this is caused by the installation files not being digitally signed with a recognized developer signature.

Are there any plans to register the installer to prevent this scary warning ?

3. Where can you see the logs (or equivalent of the Java console) ?

Thanks

[Gadi Levy]

Some more info on the url length limitation.

After testing with Chrome (latest) it seems the maximum URL length is 2046 characters (including the weasis:// prefix).

Longer urls don't get passed at all to Weasis.

(This is strange though, because Chrome itself allows for much longer URLs. Can this be a limitation of the weasis:// web protocol ?)
This means that big manifests (for big studies with many images) cannot be loaded with the -i flag. These probably need to be loaded dynamically with the - w flag.
.

[Gadi Levy]

And another update:

There seems to be a problem loading the xml manifes over https with the -w flag.
I am getting this error: Error on loading the XML Manifest from: https://<path written here - removed from this post> 

Server response: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure 

However, copying and pasting the same url in the browser produces the xml manifest document without any problems.

Needless to say the server has a valid ssl certificate and serves pages over https regularly.

Can't Weasis download the manifest over https ??

Thanks

[Nicolas Roduit]

1) Integrating the manifest into the URL is probably a bad approach and therefore the question of the length of the URL should not arise. However, the size limit of browsers is quite large except for IE.

2) The MSI packages and the Weasis executable will be signed in the future release. Weasis packages will gradually be distributed in the App Stores. This is already the case in the Windows Store (when weasis is not installed , this helps to find the required application when executing the weasis protocol).

3) Logs are available either in Weasis log files (in ${user.home}/.weasis/log) or in the Java console (only with Java Webstart). Logging can be activated in Weasis from File > Preferences > General. From 3.5.3, a boot.log file is always written to help to investigate at launch.

I recommend using the -w option and weasis-pacs-connector for downloading the manifest because the service returns an id directly and allows the manifest to be built meanwhile the launch of Weasis.

If the manifest is made elsewhere, it can be uploaded into the service without its content being in the URL.

The issue about https was the first bug found in this new release and already fixed for 3.5.4.

[Paolo Marcheschi]

Hi

Thank you for this very valuable upgrade. Thank you for your work.

I tried today the new environment on Linux and Windows and it works as expected.

The 3d stl, and pdf  handlers work fine so I can open M3D files with the default viewer or  3D printer software.

I still  need to understand how to use the weasis:// url.

Can you provide some practical example, in the way to substitute the pacs connector environment?

How can I make an url by passing the Accession number of the study, specifying the wado protocol?

Thank you

Paolo

[Nicolas Roduit]

It is not possible yet without pacs-connector but it should be in the next release. See also this post.

[Paolo Marcheschi]

Thank you Nicolas

Best Regards

Paolo

[Nicolas Roduit]

See this post to test the dcm4chee-arc-light integration without weasis-pacs-connector.

[Paolo Marcheschi]

Hi
Thank you, but i do not have the Arc-light in production yet, does it
also work on dcm4chee-web3?
Thank you
Paolo

Il giorno lun 30 set 2019 alle ore 16:49 Nicolas Roduit
<nicolas...@gmail.com> ha scritto:

> --
> You received this message because you are subscribed to a topic in the Google Groups "dcm4che" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/dcm4che/3C84sscQqkQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to dcm4che+u...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/dcm4che/b9f47bf1-30bd-4b86-ab7a-df68fdfaa755%40googlegroups.com.



--

Dott. Ing. Paolo Marcheschi


------------------------------------------
This e-mail and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to which they
are addressed.If you have received this e-mail in error please notify
the sender immediately, then delete it. Confidentiality and legal
privilege are not waived or lost by reason of mistaken delivery to
you.
------------------------------------------

[Nicolas Roduit]

No, because it is necessary to be able to make all the required requests through the DICOMWeb services (QIDO-RS and WADO-RS) which do not exist in dcm4chee-2.x.x.

On Tuesday, October 1, 2019 at 9:24:57 AM UTC+2, Paolo Marcheschi wrote:

Hi
Thank you, but i do not have the Arc-light in production yet, does it
also work on dcm4chee-web3?
Thank you
Paolo

Il giorno lun 30 set 2019 alle ore 16:49 Nicolas Roduit

 ha scritto:
>
> See this post to test the dcm4chee-arc-light integration without weasis-pacs-connector.
>
> On Friday, September 6, 2019 at 10:36:31 AM UTC+2, Paolo Marcheschi wrote:
>>
>> Thank you Nicolas
>> Best Regards
>> Paolo
>>
>> On Friday, September 6, 2019 at 9:09:56 AM UTC+2, Nicolas Roduit wrote:
>>>
>>> It is not possible yet without pacs-connector but it should be in the next release. See also this post.
>>>
>>> On Thursday, September 5, 2019 at 4:31:49 PM UTC+2, Paolo Marcheschi wrote:
>>>>
>>>> Hi
>>>> Thank you for this very valuable upgrade. Thank you for your work.
>>>> I tried today the new environment on Linux and Windows and it works as expected.
>>>> The 3d stl, and pdf  handlers work fine so I can open M3D files with the default viewer or  3D printer software.
>>>> I still  need to understand how to use the weasis:// url.
>>>> Can you provide some practical example, in the way to substitute the pacs connector environment?
>>>> How can I make an url by passing the Accession number of the study, specifying the wado protocol?
>>>>
>>>> Thank you
>>>> Paolo
>
> --
> You received this message because you are subscribed to a topic in the Google Groups "dcm4che" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/dcm4che/3C84sscQqkQ/unsubscribe.

> To unsubscribe from this group and all its topics, send an email to dcm4che+unsubscribe@googlegroups.com.

[Paolo Marcheschi]

Ok Thank you

But if I use the weasis pacs connector I can still use dcm4chee-web3 with the new desktop installed weasis via a call like this:

http://localhost:8080/weasis-pacs-connector/weasis?accessionNumber=3224252

Correct?

Or to use the new weasis (with its own JVM) I have to switch to the new arc-light?

Thank you

Paolo

> To unsubscribe from this group and all its topics, send an email to dcm...@googlegroups.com.

[Nicolas Roduit]

Yes you can use the new native installer and dcm4chee-2.x with weasis-pacs-connector 6.1.5 and the jmx configuration: WebviewerBaseUrl = weasis:/weasis-pacs-connector/weasis

See https://nroduit.github.io/en/getting-started/dcm4chee/#for-dcm4chee-web3

[Paolo Marcheschi]

Thank you

We tried and it works as expected.

Best regards

Paolo