Hi Romain,
Thanks for the feedback. Just to make sure we are on the same page I am
proposing that this desktop extension would be packaged like the other
component extensions, distributed in a separate jar that could be included only
by those would like to use it.
Also this extension would be used to configure Meecrowave as a standalone local
web server intended to only be accessed by a single local desktop user.
Meecrowave would be configured to bind Tomcat only to the loopback interface
127.0.0.1 so no external access to it would be allowed. This single user
configuration is quite different from the standard open multi user
configuration.
Another thing to consider is that all of the extension's activity occurs after
Meecrowave is started but before the application is deployed.
Here are my responses to your comments below:
1) System Tray - java.awt.SystemTray -Right now I only configured it with a
shutdown option but it could be injectable via CDI so that it could be further
customized by the application.
2) Browser Launch - java.awt.Desktop#browse - This launches the native OS
browser and not a java based embedded browser. For instance in Linux I have
chrome setup as my native browser and that launches with the address
prepopulated to the local Meecrowave application home page. On Windows Edge
launches.
3) Interactive Auth - For a single user instance of Meecrowave this interactive
authentication mechanism "unlocks" the Derby database so that it is open for
other connections later. Once the initial bootPassword is provided the
credentials are not needed to connect to the database again until it is
intentionally shutdown. Specifying the password before the application starts
allows for a standard JPA configuration without adding the complexity of
managing a JPA datasource password configuration.
4) OAuthClient - This was needed for my configuration since my update files are
on a protected site that requires authentication. This is a configurable option
and could only be enabled as needed.
5 &6) Update - the update site works similar to the eclipse p2 update sites.
The update site has three files, a single simple Json manifest file that
contains the version information and file names of the Meecrowave runner jar
and application war files and then the two files themselves. All communication
with the update site is performed over HTTPS using a JAX-RS 2 client. I just
store my artifacts in an S3 bucket and have a simple JAX-RS endpoint that reads
from it. This update process is supposed to only run during the Meecrowave
startup process configured for single use. The target platform is a
non-technical user's desktop with little to no administrative priviledges.
While Maven artifacts are a good fit for build management artifact resolution
it is very complex and requires a large number of dependencies making it less
than ideal for software asset provisioning. As I mentioned before I tried to
use WebStart and also setup an eclipse update site for my application but I
couldn't find a simple Java application provisioning library that satisfied my
requirements with Meecrowave.
Regards,
Aaron
On Thursday, February 1, 2018 1:18 AM, Romain Manni-Bucau
<[email protected]> wrote:
Some comments inline - please take it as clarification requests more than a
reject or anything else
Le 1 févr. 2018 07:19, "Aaron Anderson" <[email protected]> a écrit :
Hi Meecrowave developers and users,
I am nearly finished working on a Meecrowave extension for enhancing Meecrowave
to be a desktop platform. Here is some background on my work:
For some time I have been working on a desktop application that manages very
sensitive data. The data it manages must be encrypted at rest and requires
password authentication to start it. The application cannot be Cloud based. The
application will be used by several dozen users so it needs to have an update
mechanism where I can push out updates. I can't make the application purely
JavaScript/Browser base since I need to use some Java libraries to access and
manipulate the data.
I am familiar with Applets and Java WebStart but those are now dead
technologies. I actually built out an application using e(fx)clipse which is
based on JavaFX and the eclipse RCP platform but my update libraries are behind
an oauth protected web site and it took a tremendous amount of work to get the
update site feature to work. It was also laborious for me to build the UI in
JavaFX since that requires specialized knowledge that I don't use day to day.
This brings me to Meecrowave. In the past I have used several commercial
Windows applications that actually ran Tomcat as a service to render their
presentation view for their application. I am also working on a server side
application as well so using the same UI framework (Polymer) on both the client
and server is appealing to me.
I started to build my client application using WildFly-Swarm but the file size
(130mb) was a little extreme considering I wanted support frequent updates.
Meecrowave addressed all of my concerns with cutting edge API support, quick
startup times, and small dependency sizes (25mb for my runner and 11mb for my
application).
Now getting to my potential contribution, I have added several features to
Meecrowave to make it more desktop friendly:
1) System Tray - If one runs the Meecrowave jar as a java application it runs
in the background and there is visible cue it is accessible. I used the Java
AWT system tray to add an icon with a shutdown option to cleanly shutdown the
server.
We can have a module for it but IIRC code was not that hard and highly specific
for the menu etc, no?Also we must stay portable here.
2 Browser launch - Again I used the AWT desktop API provided with Java to
launch a browser instance to open the applications home page once the
application is started.
Is it a plain browser? Javafx weview doesnt work with angular for instance
which is a blocker.Used an embed browser as an alternative or a plain electron
app with mw as server. Works not bad.
3) Interactive Authentication with Derby - As I mentioned my application
requires local authentication in order to decrypt the data. I built several
Java swing forms for password creation, change, and authentication. These
credentials are used to create or start an embedded Apache Derby database using
AES 256 encryption.
Why not using a tomcat realm and stay pluggable?
4) OAuth Client Support - My application updates and remote resources are
protected by an OIDC OAuth IDP so I built in a local OAuth JAX-RS client that
manages refresh tokens in the Apache derby database. There are several examples
of using CXF as an OAuth server but there is hardly any documentation on using
CXF with a pure JAX-RS 2.0 client to interact with OAuth systems.
Hmm, think cxf has it - maybe not the db support but it is not that mandatory
with oauth. Can be a cxf contrib though.
5) Update support - I built an update process that can independently update the
runner jar and application war. It performs several actions like checking the
local versions, fetching a version manifest file from a remote protected HTTPS
server, downloading updated jar files, and rendering several Java swing forms
to display the update status in real time.
Im interesting in that - in headless/pluggable mode - but I d do maybe
something more generic like an incubator project maybe.
6) Finally I built a simple CLI release manager that queries the local maven
repository for version information and then injects version manifest files into
a copy of the selected artifacts, jar signs them, and then uploads them to a
central server. Currently my release manager uploads the update files to an AWS
S3 bucket that my server application reads from but I can adjust it to publish
to an SFTP server.
Guess we will stick to maven/nexus/artifactory for this kind of things to avoid
a custom implementation and costly one (s3 is quickly too expensive)
I have tested these enhancements on both Linux and Windows. The system tray
doesn't work on my Linux system very well but everything else does. I also had
contributing this code in mind when I developed it so I tried to make
everything plugable and configurable.
Please let me know if there is any interest in having these features
contributed to the Meecrowave project as an extension. If so I can start to
work on a github pull request.
Regards,
Aaron
