You are viewing a plain text version of this content. The canonical link for it is here.

Posted to user@openwebbeans.apache.org by Aaron Anderson <aa...@acm.org> on 2018/02/01 06:19:13 UTC

Desktop Meecrowave extension contribution

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.
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.
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.
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.
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.
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.

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

Re: Desktop Meecrowave extension contribution

Posted by Aaron Anderson <aa...@acm.org>.

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 <rm...@gmail.com> 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" <aa...@acm.org> a écrit :

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)

Re: Desktop Meecrowave extension contribution

Posted by Romain Manni-Bucau <rm...@gmail.com>.

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" <aa...@acm.org> 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

Re: Desktop Meecrowave extension contribution

Posted by Aaron Anderson <aa...@acm.org>.

Hi All,
I uploaded my desktop extension to my Meecrowave fork in github:
https://github.com/aaronanderson/meecrowave/tree/desktop/meecrowave-desktop

At the moment the tests are not functional but I will take some time to address that in a few days. For now please feel free to take a look at the codebase and let me know what you think.
Regards,
Aaron 

    On Friday, February 2, 2018 2:18 AM, Mark Struberg <st...@yahoo.de> wrote:
 

 Hi Aaron!

This sounds like extremely useful work!
I hope you enjoyed digging into OWB and Meecrowave and of course we do highly welcome your contributions back to the project :)

Is the code available anywhere already?
Looking forward to work with you!

@Romain incubator whould be an overkill for now I think.
I agree that such an update mechanism might become more generic in the end. 
But I'd still start with it over here and then if it works fine we can extract it out into a component and make it more reusable.

>> 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)

Yes, using something like Nexus or Archiva might be perfectly fine.
But I'd be not so quick judging before knowing Aarons exact use case. 


> 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

+1

> 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

Yes, Maven is surely more complex than needed for just file serving. 
Otto it's a standard infrastructure item which doesn't require any maintenance.
Btw re Maven: we might enhance our meecrowave-maven-plugin to package up and deploy such a 'release'.
Regardless whether this is handled as attached-artifacts in a Maven repo or done via scp, sftp, etc.
Again: would need to dig deeper to understand the exact need and solution.



txs and LieGrue,
strub


> Am 01.02.2018 um 07:19 schrieb Aaron Anderson <aa...@acm.org>:
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 
> 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

Re: Desktop Meecrowave extension contribution

Posted by Romain Manni-Bucau <rm...@gmail.com>.

quick advice: maybe start by the already agreed parts and do it iteratively
instead of putting it all at once, will allow to merge faster ;)

side note: we are in the process of planning a release, not sure it can be
in but dont worry if not we can release later without issues


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>

2018-02-02 14:43 GMT+01:00 Aaron Anderson <aa...@acm.org>:

> Hi Mark and Romain,
>
> I will go ahead and create a github fork of meecrowave and commit my
> current work there. I was looking for affirmation that this contribution
> could possibly be accepted before I went through the effort of renaming all
> of the packages. If the contribution is accepted that will be great
> otherwise it will be available on my fork for others to publicly access.
>
> I previously contributed to the Apache ODE project so my Apache Individual
> Contributor License Agreement should still be on file.
>
> Once my fork is ready for review I will create a new thread on the
> development list.
>
> Regards,
>
> Aaron
>
>
> On Friday, February 2, 2018 2:25 AM, Romain Manni-Bucau <
> rmannibucau@gmail.com> wrote:
>
>
> I see, my fear about desktop API is it doesn't work well (browse() worked
> 50% of the times on the computers I got in the last 5 years for instance, I
> didnt set it up, right, but also not a great default). That said we can
> easily replace it by an exec with config + good default guess algorithm.
>
> The system tray is interesting for me and I'm happy to test it on ubuntu
> again.
>
> I'm less convinced by the 3 but I can need to see the code to be more
> accurate, for now it looks overkill for me but can be a "mail reading"
> issue.
>
> 4 clearly belongs to CXF directly for me.
>
> the update is very cool and I'm fine with Mark saying we do it here then
> maybe generify it.
>
> the resolution should however clearly be maven friendly for me since it is
> the mainstream and the way to be the most usable. Resolution is very easy
> without maven stack or any dependency and with no dep: grab
> https://github.com/apache/tomee/blob/master/container/openejb-loader/src/
> main/java/org/apache/openejb/loader/provisining/MavenResolver.java and
> https://github.com/apache/tomee/blob/master/container/
> openejb-loader/src/main/java/org/apache/openejb/loader/
> provisining/HttpResolver.java - code dependencies are easy to import, it
> is mainly sugar utilities we can copy over and it is a few code. I see i a
> bit like OSGi features.xml, you get a list of artifact (your manifest) and
> then grab it from coordinates (http, mvn, local filesystem?, ...). Don't
> get me wrong, I'm not against supporting s3: as an optional extension but
> 1. it shouldn't require any dependency (no aws sdk) by default, and 2. it
> should be compatible with a plain maven repo (httpd proxy) to be usable by
> most people.
>
> Hope it makes sense.
>
> 2018-02-02 9:17 GMT+01:00 Mark Struberg <st...@yahoo.de>:
>
> Hi Aaron!
>
> This sounds like extremely useful work!
> I hope you enjoyed digging into OWB and Meecrowave and of course we do
> highly welcome your contributions back to the project :)
>
> Is the code available anywhere already?
> Looking forward to work with you!
>
> @Romain incubator whould be an overkill for now I think.
> I agree that such an update mechanism might become more generic in the end.
> But I'd still start with it over here and then if it works fine we can
> extract it out into a component and make it more reusable.
>
> >> 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)
>
> Yes, using something like Nexus or Archiva might be perfectly fine.
> But I'd be not so quick judging before knowing Aarons exact use case.
>
>
> > 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
>
> +1
>
> > 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
>
> Yes, Maven is surely more complex than needed for just file serving.
> Otto it's a standard infrastructure item which doesn't require any
> maintenance.
> Btw re Maven: we might enhance our meecrowave-maven-plugin to package up
> and deploy such a 'release'.
> Regardless whether this is handled as attached-artifacts in a Maven repo
> or done via scp, sftp, etc.
> Again: would need to dig deeper to understand the exact need and solution.
>
>
>
> txs and LieGrue,
> strub
>
>
> > Am 01.02.2018 um 07:19 schrieb Aaron Anderson <aa...@acm.org>:
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> >
> > 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
>
>
>
>
>

Re: Desktop Meecrowave extension contribution

Posted by Mark Struberg <st...@yahoo.de>.

+1 having a iCLA is a good thing to start ;)

LieGrue,
strub


> Am 02.02.2018 um 14:43 schrieb Aaron Anderson <aa...@acm.org>:
> 
> Hi Mark and Romain,
> 
> I will go ahead and create a github fork of meecrowave and commit my current work there. I was looking for affirmation that this contribution could possibly be accepted before I went through the effort of renaming all of the packages. If the contribution is accepted that will be great otherwise it will be available on my fork for others to publicly access.
> 
> I previously contributed to the Apache ODE project so my Apache Individual Contributor License Agreement should still be on file.
> 
> Once my fork is ready for review I will create a new thread on the development list.
> 
> Regards,
> 
> Aaron
> 
> 
> On Friday, February 2, 2018 2:25 AM, Romain Manni-Bucau <rm...@gmail.com> wrote:
> 
> 
> I see, my fear about desktop API is it doesn't work well (browse() worked 50% of the times on the computers I got in the last 5 years for instance, I didnt set it up, right, but also not a great default). That said we can easily replace it by an exec with config + good default guess algorithm.
> 
> The system tray is interesting for me and I'm happy to test it on ubuntu again.
> 
> I'm less convinced by the 3 but I can need to see the code to be more accurate, for now it looks overkill for me but can be a "mail reading" issue.
> 
> 4 clearly belongs to CXF directly for me.
> 
> the update is very cool and I'm fine with Mark saying we do it here then maybe generify it.
> 
> the resolution should however clearly be maven friendly for me since it is the mainstream and the way to be the most usable. Resolution is very easy without maven stack or any dependency and with no dep: grab https://github.com/apache/tomee/blob/master/container/openejb-loader/src/main/java/org/apache/openejb/loader/provisining/MavenResolver.java and https://github.com/apache/tomee/blob/master/container/openejb-loader/src/main/java/org/apache/openejb/loader/provisining/HttpResolver.java - code dependencies are easy to import, it is mainly sugar utilities we can copy over and it is a few code. I see i a bit like OSGi features.xml, you get a list of artifact (your manifest) and then grab it from coordinates (http, mvn, local filesystem?, ...). Don't get me wrong, I'm not against supporting s3: as an optional extension but 1. it shouldn't require any dependency (no aws sdk) by default, and 2. it should be compatible with a plain maven repo (httpd proxy) to be usable by most people.
> 
> Hope it makes sense.
> 
> 2018-02-02 9:17 GMT+01:00 Mark Struberg <st...@yahoo.de>:
> Hi Aaron!
> 
> This sounds like extremely useful work!
> I hope you enjoyed digging into OWB and Meecrowave and of course we do highly welcome your contributions back to the project :)
> 
> Is the code available anywhere already?
> Looking forward to work with you!
> 
> @Romain incubator whould be an overkill for now I think.
> I agree that such an update mechanism might become more generic in the end.
> But I'd still start with it over here and then if it works fine we can extract it out into a component and make it more reusable.
> 
> >> 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)
> 
> Yes, using something like Nexus or Archiva might be perfectly fine.
> But I'd be not so quick judging before knowing Aarons exact use case.
> 
> 
> > 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
> 
> +1
> 
> > 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
> 
> Yes, Maven is surely more complex than needed for just file serving.
> Otto it's a standard infrastructure item which doesn't require any maintenance.
> Btw re Maven: we might enhance our meecrowave-maven-plugin to package up and deploy such a 'release'.
> Regardless whether this is handled as attached-artifacts in a Maven repo or done via scp, sftp, etc.
> Again: would need to dig deeper to understand the exact need and solution.
> 
> 
> 
> txs and LieGrue,
> strub
> 
> 
> > Am 01.02.2018 um 07:19 schrieb Aaron Anderson <aa...@acm.org>:
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> >
> > 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
> 
> 
> 
>

Re: Desktop Meecrowave extension contribution

Posted by Aaron Anderson <aa...@acm.org>.

Hi Mark and Romain,
I will go ahead and create a github fork of meecrowave and commit my current work there. I was looking for affirmation that this contribution could possibly be accepted before I went through the effort of renaming all of the packages. If the contribution is accepted that will be great otherwise it will be available on my fork for others to publicly access.
I previously contributed to the Apache ODE project so my Apache Individual Contributor License Agreement should still be on file.
Once my fork is ready for review I will create a new thread on the development list.
Regards,
Aaron 

    On Friday, February 2, 2018 2:25 AM, Romain Manni-Bucau <rm...@gmail.com> wrote:

 I see, my fear about desktop API is it doesn't work well (browse() worked 50% of the times on the computers I got in the last 5 years for instance, I didnt set it up, right, but also not a great default). That said we can easily replace it by an exec with config + good default guess algorithm.
The system tray is interesting for me and I'm happy to test it on ubuntu again.
I'm less convinced by the 3 but I can need to see the code to be more accurate, for now it looks overkill for me but can be a "mail reading" issue.
4 clearly belongs to CXF directly for me.
the update is very cool and I'm fine with Mark saying we do it here then maybe generify it.
the resolution should however clearly be maven friendly for me since it is the mainstream and the way to be the most usable. Resolution is very easy without maven stack or any dependency and with no dep: grab https://github.com/apache/tomee/blob/master/container/openejb-loader/src/main/java/org/apache/openejb/loader/provisining/MavenResolver.java and https://github.com/apache/tomee/blob/master/container/openejb-loader/src/main/java/org/apache/openejb/loader/provisining/HttpResolver.java - code dependencies are easy to import, it is mainly sugar utilities we can copy over and it is a few code. I see i a bit like OSGi features.xml, you get a list of artifact (your manifest) and then grab it from coordinates (http, mvn, local filesystem?, ...). Don't get me wrong, I'm not against supporting s3: as an optional extension but 1. it shouldn't require any dependency (no aws sdk) by default, and 2. it should be compatible with a plain maven repo (httpd proxy) to be usable by most people.
Hope it makes sense.
2018-02-02 9:17 GMT+01:00 Mark Struberg <st...@yahoo.de>:

Hi Aaron!

This sounds like extremely useful work!
I hope you enjoyed digging into OWB and Meecrowave and of course we do highly welcome your contributions back to the project :)

Is the code available anywhere already?
Looking forward to work with you!

@Romain incubator whould be an overkill for now I think.
I agree that such an update mechanism might become more generic in the end.
But I'd still start with it over here and then if it works fine we can extract it out into a component and make it more reusable.

>> 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)

Yes, using something like Nexus or Archiva might be perfectly fine.
But I'd be not so quick judging before knowing Aarons exact use case.

> 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

+1

> 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

Yes, Maven is surely more complex than needed for just file serving.
Otto it's a standard infrastructure item which doesn't require any maintenance.
Btw re Maven: we might enhance our meecrowave-maven-plugin to package up and deploy such a 'release'.
Regardless whether this is handled as attached-artifacts in a Maven repo or done via scp, sftp, etc.
Again: would need to dig deeper to understand the exact need and solution.

txs and LieGrue,
strub

> Am 01.02.2018 um 07:19 schrieb Aaron Anderson <aa...@acm.org>:
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
>
> 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

Re: Desktop Meecrowave extension contribution

Posted by Mark Struberg <st...@yahoo.de>.


> Am 02.02.2018 um 09:25 schrieb Romain Manni-Bucau <rm...@gmail.com>:
> 
> the update is very cool and I'm fine with Mark saying we do it here then maybe generify it.


I thought about the update a bit longer. 
A core issue with updates is to _not_ pick up faulty/dangerous updates.
So we might do something like bundling a public key to the distribution. 
Then bundle the updates/new version with a private key of the company.
That means that the update mechanism can verify the upgrade binaries before he accepts it.
That would allow to be an additional prevent against fraud.

Not sure if it's worth it and whether it's necessary at all though.

LieGrue,
strub

Re: Desktop Meecrowave extension contribution

Posted by Romain Manni-Bucau <rm...@gmail.com>.

I see, my fear about desktop API is it doesn't work well (browse() worked
50% of the times on the computers I got in the last 5 years for instance, I
didnt set it up, right, but also not a great default). That said we can
easily replace it by an exec with config + good default guess algorithm.

The system tray is interesting for me and I'm happy to test it on ubuntu
again.

I'm less convinced by the 3 but I can need to see the code to be more
accurate, for now it looks overkill for me but can be a "mail reading"
issue.

4 clearly belongs to CXF directly for me.

the update is very cool and I'm fine with Mark saying we do it here then
maybe generify it.

the resolution should however clearly be maven friendly for me since it is
the mainstream and the way to be the most usable. Resolution is very easy
without maven stack or any dependency and with no dep: grab
https://github.com/apache/tomee/blob/master/container/openejb-loader/src/main/java/org/apache/openejb/loader/provisining/MavenResolver.java
and
https://github.com/apache/tomee/blob/master/container/openejb-loader/src/main/java/org/apache/openejb/loader/provisining/HttpResolver.java
- code dependencies are easy to import, it is mainly sugar utilities we can
copy over and it is a few code. I see i a bit like OSGi features.xml, you
get a list of artifact (your manifest) and then grab it from coordinates
(http, mvn, local filesystem?, ...). Don't get me wrong, I'm not against
supporting s3: as an optional extension but 1. it shouldn't require any
dependency (no aws sdk) by default, and 2. it should be compatible with a
plain maven repo (httpd proxy) to be usable by most people.

Hope it makes sense.

2018-02-02 9:17 GMT+01:00 Mark Struberg <st...@yahoo.de>:

> Hi Aaron!
>
> This sounds like extremely useful work!
> I hope you enjoyed digging into OWB and Meecrowave and of course we do
> highly welcome your contributions back to the project :)
>
> Is the code available anywhere already?
> Looking forward to work with you!
>
> @Romain incubator whould be an overkill for now I think.
> I agree that such an update mechanism might become more generic in the end.
> But I'd still start with it over here and then if it works fine we can
> extract it out into a component and make it more reusable.
>
> >> 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)
>
> Yes, using something like Nexus or Archiva might be perfectly fine.
> But I'd be not so quick judging before knowing Aarons exact use case.
>
>
> > 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
>
> +1
>
> > 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
>
> Yes, Maven is surely more complex than needed for just file serving.
> Otto it's a standard infrastructure item which doesn't require any
> maintenance.
> Btw re Maven: we might enhance our meecrowave-maven-plugin to package up
> and deploy such a 'release'.
> Regardless whether this is handled as attached-artifacts in a Maven repo
> or done via scp, sftp, etc.
> Again: would need to dig deeper to understand the exact need and solution.
>
>
>
> txs and LieGrue,
> strub
>
>
> > Am 01.02.2018 um 07:19 schrieb Aaron Anderson <aa...@acm.org>:
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> >
> > 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
>
>

Re: Desktop Meecrowave extension contribution

Posted by Romain Manni-Bucau <rm...@gmail.com>.

Mw extension ;)

Le 2 févr. 2018 21:03, "Mark Struberg" <st...@yahoo.de> a écrit :

> With 'Extension' do you mean CDI Extension?
>
> I was thinking about this the other day and thought it might be cool to
> have an exclude list in OWB directly.
> So with the openwebbeans.properties you might be able to have a list of
> fqcn of the Extensions to ignore.
>
> Not sure whether this is in the direction you were thinking.
>
> LieGrue,
> strub
>
> > Am 02.02.2018 um 15:12 schrieb Aaron Anderson <aa...@acm.org>:
> >
> > Hi Mark,
> >
> > My experience with creating a contribution was overall positive. I did
> encounter a few of issues that I had to work around:
> >
> > 1) meecrowave.properties and CLI binding - I have several options
> classes that I registered as Cli.Options service loader extensions and I
> was able to obtain the commandline provided values without a problem.
> However additionally I wanted to bind meecrowave.properties values to the
> same options instance so I could access both the CLI values and configured
> values. From what I can tell the CLI values and properties are mutually
> exclusive, i.e. one can't override a properties file set value with a CLI
> value like in most apps. In any event when I tried to include my extension
> options in meecrowave.properties they were never available either before or
> after meecrowave started. I ended up creating a separate properties file
> and manually loading it using builder.setProperties(myProperties) and
> then builder.getExtension(CliExtOptions.class);
> >
> > 2) Add support of interfaces for extensions - I have several plugable
> interfaces I am using and it would have been nice to be able to register
> extensions instead of the extension automatically being instantiated. For
> example builder.addExtension(MyInterface.class,MyImplObject) and
> builder.getExtension(MyInterface.class) != null? .... Right now a
> reference to the concrete implementation class always needs to be retained
> to lookup an extension.
> >
> > 3) CDI support for objects instantiated in the extention - This was by
> far my biggest headache and I spent a couple of hours trying to get this to
> work. Basically I wanted to create a single instance of my OAuthClient that
> was configured via properties and have that be injectable into the running
> application. I wanted a configuration exactly like OWBAutoSetup,java that
> registers Meecrowave and it's builder as being injectable. I tried multiple
> attempts of adding a Tomcat listener to call the
> WebBeansContext.getInstance() in the right classloader with the same
> beanManager.addInternalBean logic but my listener was always called too
> late. This is where my request to allow extensions to add
> servletcontextlisteners originated from.
> >
> >
> > I ended up creating a CDI extension that works around the issue by
> leveraging the Meecrowave extension feature to lookup the configured
> instance:
> >
> > public class WebAuthenticatorCDIExtension implements Extension {
> >       WebAuthenticator webAuthenticator;
> >
> >
> >       //I am not sure how OAuth2WebAuthenticator was discovered by
> openwebbeans but it needs to be vetoed to avoid an ambiguous dependency
> exception with the unmanaged bean below.
> >       void processAnnotatedType(@Observes ProcessAnnotatedType<OAuth2WebAuthenticator>
> pat) {
> >               pat.veto();
> >       }
> >
> >       void addBeans(@Observes final AfterBeanDiscovery afb, final
> BeanManager bm) {
> >               afb.addBean().beanClass(WebAuthenticator.class).scope(
> ApplicationScoped.class).types(WebAuthenticator.class,
> Object.class).qualifiers(DefaultLiteral.INSTANCE).createWith(cc -> {
> >                       return webAuthenticator;
> >               });
> >
> >       }
> >
> >       void initBeans(@Observes final AfterDeploymentValidation adv,
> final BeanManager bm) {
> >               //copied from JPA Extension
> >               try {
> >                       final ServletContext sc =
> ServletContext.class.cast(bm.getReference(bm.resolve(bm.
> getBeans(ServletContext.class)), ServletContext.class,
> bm.createCreationalContext(null)));
> >                       Meecrowave.Builder config =
> Meecrowave.Builder.class.cast(sc.getAttribute("meecrowave.
> configuration"));
> >                       ResourceFinder finder = new
> ResourceFinder("META-INF/services/");
> >                       Class<?> webAuthenticatorImpl =
> finder.findImplementation(WebAuthenticator.class);
> >                       if (webAuthenticatorImpl != null) {
> >                               webAuthenticator = (WebAuthenticator)
> config.getExtension(webAuthenticatorImpl);
> >                       }
> >               } catch (Exception e) {
> >                       adv.addDeploymentProblem(e);
> >               }
> >       }
> >
> > }
> >
> > Is there a better  way to expose extension instances to the application
> for injection? Is there a way to add other instances to the ServletContext?
> >
> > Regards,
> >
> > Aaron
> >
> >
> > On Friday, February 2, 2018 2:18 AM, Mark Struberg <st...@yahoo.de>
> wrote:
> >
> >
> > Hi Aaron!
> >
> > This sounds like extremely useful work!
> > I hope you enjoyed digging into OWB and Meecrowave and of course we do
> highly welcome your contributions back to the project :)
> >
> > Is the code available anywhere already?
> > Looking forward to work with you!
> >
> > @Romain incubator whould be an overkill for now I think.
> > I agree that such an update mechanism might become more generic in the
> end.
> > But I'd still start with it over here and then if it works fine we can
> extract it out into a component and make it more reusable.
> >
> > >> 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)
> >
> > Yes, using something like Nexus or Archiva might be perfectly fine.
> > But I'd be not so quick judging before knowing Aarons exact use case.
> >
> >
> > > 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
> >
> > +1
> >
> > > 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
> >
> > Yes, Maven is surely more complex than needed for just file serving.
> > Otto it's a standard infrastructure item which doesn't require any
> maintenance.
> > Btw re Maven: we might enhance our meecrowave-maven-plugin to package up
> and deploy such a 'release'.
> > Regardless whether this is handled as attached-artifacts in a Maven repo
> or done via scp, sftp, etc.
> > Again: would need to dig deeper to understand the exact need and
> solution.
> >
> >
> >
> > txs and LieGrue,
> > strub
> >
> >
> > > Am 01.02.2018 um 07:19 schrieb Aaron Anderson <aa...@acm.org>:
> > >
> > > 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.
> > >
> > > 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.
> > >
> > > 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.
> > >
> > > 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.
> > >
> > > 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.
> > >
> > > 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.
> > >
> > >
> > > 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
> >
> >
>
>

Re: Desktop Meecrowave extension contribution

Posted by Mark Struberg <st...@yahoo.de>.

With 'Extension' do you mean CDI Extension?

I was thinking about this the other day and thought it might be cool to have an exclude list in OWB directly.
So with the openwebbeans.properties you might be able to have a list of fqcn of the Extensions to ignore.

Not sure whether this is in the direction you were thinking.

LieGrue,
strub

> Am 02.02.2018 um 15:12 schrieb Aaron Anderson <aa...@acm.org>:
> 
> Hi Mark,
> 
> My experience with creating a contribution was overall positive. I did encounter a few of issues that I had to work around:
> 
> 1) meecrowave.properties and CLI binding - I have several options classes that I registered as Cli.Options service loader extensions and I was able to obtain the commandline provided values without a problem. However additionally I wanted to bind meecrowave.properties values to the same options instance so I could access both the CLI values and configured values. From what I can tell the CLI values and properties are mutually exclusive, i.e. one can't override a properties file set value with a CLI value like in most apps. In any event when I tried to include my extension options in meecrowave.properties they were never available either before or after meecrowave started. I ended up creating a separate properties file and manually loading it using builder.setProperties(myProperties) and then builder.getExtension(CliExtOptions.class);
> 
> 2) Add support of interfaces for extensions - I have several plugable interfaces I am using and it would have been nice to be able to register extensions instead of the extension automatically being instantiated. For example builder.addExtension(MyInterface.class,MyImplObject) and builder.getExtension(MyInterface.class) != null? .... Right now a reference to the concrete implementation class always needs to be retained to lookup an extension.
> 
> 3) CDI support for objects instantiated in the extention - This was by far my biggest headache and I spent a couple of hours trying to get this to work. Basically I wanted to create a single instance of my OAuthClient that was configured via properties and have that be injectable into the running application. I wanted a configuration exactly like OWBAutoSetup,java that registers Meecrowave and it's builder as being injectable. I tried multiple attempts of adding a Tomcat listener to call the WebBeansContext.getInstance() in the right classloader with the same beanManager.addInternalBean logic but my listener was always called too late. This is where my request to allow extensions to add servletcontextlisteners originated from.
> 
> 
> I ended up creating a CDI extension that works around the issue by leveraging the Meecrowave extension feature to lookup the configured instance:
> 
> public class WebAuthenticatorCDIExtension implements Extension {
> 	WebAuthenticator webAuthenticator;
> 
> 
> 	//I am not sure how OAuth2WebAuthenticator was discovered by openwebbeans but it needs to be vetoed to avoid an ambiguous dependency exception with the unmanaged bean below.
> 	void processAnnotatedType(@Observes ProcessAnnotatedType<OAuth2WebAuthenticator> pat) {
> 		pat.veto();
> 	}
> 
> 	void addBeans(@Observes final AfterBeanDiscovery afb, final BeanManager bm) {
> 		afb.addBean().beanClass(WebAuthenticator.class).scope(ApplicationScoped.class).types(WebAuthenticator.class, Object.class).qualifiers(DefaultLiteral.INSTANCE).createWith(cc -> {
> 			return webAuthenticator;
> 		});
> 
> 	}
> 
> 	void initBeans(@Observes final AfterDeploymentValidation adv, final BeanManager bm) {
> 		//copied from JPA Extension
> 		try {
> 			final ServletContext sc = ServletContext.class.cast(bm.getReference(bm.resolve(bm.getBeans(ServletContext.class)), ServletContext.class, bm.createCreationalContext(null)));
> 			Meecrowave.Builder config = Meecrowave.Builder.class.cast(sc.getAttribute("meecrowave.configuration"));
> 			ResourceFinder finder = new ResourceFinder("META-INF/services/");
> 			Class<?> webAuthenticatorImpl = finder.findImplementation(WebAuthenticator.class);
> 			if (webAuthenticatorImpl != null) {
> 				webAuthenticator = (WebAuthenticator) config.getExtension(webAuthenticatorImpl);
> 			}
> 		} catch (Exception e) {
> 			adv.addDeploymentProblem(e);
> 		}
> 	}
> 
> }
> 
> Is there a better  way to expose extension instances to the application for injection? Is there a way to add other instances to the ServletContext?
> 
> Regards,
> 
> Aaron
> 
> 
> On Friday, February 2, 2018 2:18 AM, Mark Struberg <st...@yahoo.de> wrote:
> 
> 
> Hi Aaron!
> 
> This sounds like extremely useful work!
> I hope you enjoyed digging into OWB and Meecrowave and of course we do highly welcome your contributions back to the project :)
> 
> Is the code available anywhere already?
> Looking forward to work with you!
> 
> @Romain incubator whould be an overkill for now I think.
> I agree that such an update mechanism might become more generic in the end. 
> But I'd still start with it over here and then if it works fine we can extract it out into a component and make it more reusable.
> 
> >> 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)
> 
> Yes, using something like Nexus or Archiva might be perfectly fine.
> But I'd be not so quick judging before knowing Aarons exact use case. 
> 
> 
> > 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
> 
> +1
> 
> > 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
> 
> Yes, Maven is surely more complex than needed for just file serving. 
> Otto it's a standard infrastructure item which doesn't require any maintenance.
> Btw re Maven: we might enhance our meecrowave-maven-plugin to package up and deploy such a 'release'.
> Regardless whether this is handled as attached-artifacts in a Maven repo or done via scp, sftp, etc.
> Again: would need to dig deeper to understand the exact need and solution.
> 
> 
> 
> txs and LieGrue,
> strub
> 
> 
> > Am 01.02.2018 um 07:19 schrieb Aaron Anderson <aa...@acm.org>:
> > 
> > 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.
> > 
> > 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.
> > 
> > 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.
> > 
> > 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.
> > 
> > 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.
> > 
> > 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.
> > 
> > 
> > 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
> 
>

Re: Desktop Meecrowave extension contribution

Posted by Romain Manni-Bucau <rm...@gmail.com>.

Hi Aaron,



2018-02-02 15:12 GMT+01:00 Aaron Anderson <aa...@acm.org>:

> Hi Mark,
>
> My experience with creating a contribution was overall positive. I did
> encounter a few of issues that I had to work around:
>
> 1) meecrowave.properties and CLI binding - I have several options classes
> that I registered as Cli.Options service loader extensions and I was able
> to obtain the commandline provided values without a problem. However
> additionally I wanted to bind meecrowave.properties values to the same
> options instance so I could access both the CLI values and configured
> values. From what I can tell the CLI values and properties are mutually
> exclusive, i.e. one can't override a properties file set value with a CLI
> value like in most apps. In any event when I tried to include my extension
> options in meecrowave.properties they were never available either before or
> after meecrowave started. I ended up creating a separate properties file
> and manually loading it using builder.setProperties(myProperties) and
> then builder.getExtension(CliExtOptions.class);
>

Cli should override properties, not sure we test it yet but sounds the only
viable solution. Feel free to do a PR to fix this one.


>
> 2) Add support of interfaces for extensions - I have several plugable
> interfaces I am using and it would have been nice to be able to register
> extensions instead of the extension automatically being instantiated. For
> example builder.addExtension(MyInterface.class,MyImplObject) and
> builder.getExtension(MyInterface.class) != null? .... Right now a
> reference to the concrete implementation class always needs to be retained
> to lookup an extension.
>

This was intended to enforce to keep the configuration anemic - note
configuration must not be pluggable. Background on that is that if you need
something pluggable or so you will likely use CDI capabilities and just
read/inject the "static" configuration.


>
> 3) CDI support for objects instantiated in the extention - This was by far
> my biggest headache and I spent a couple of hours trying to get this to
> work. Basically I wanted to create a single instance of my OAuthClient that
> was configured via properties and have that be injectable into the running
> application. I wanted a configuration exactly like OWBAutoSetup,java that
> registers Meecrowave and it's builder as being injectable. I tried multiple
> attempts of adding a Tomcat listener to call the
> WebBeansContext.getInstance() in the right classloader with the
> same beanManager.addInternalBean logic but my listener was always called
> too late. This is where my request to allow extensions to add
> servletcontextlisteners originated from.
>

In AfterDeploymentValidation you can lookup the builder instance (like you
looked up the ServletContext basically) and just read the extension; After
concretely you can always ass an initializer -> filter/servlet and let it
be passthrough if nothing needs to be done. This way you have the earger
init working and the lazy config reading working as well.

That said in meecrowave we made the initializers able to read the Builder
instance directly through the context.


>
>
> I ended up creating a CDI extension that works around the issue by
> leveraging the Meecrowave extension feature to lookup the configured
> instance:
>
> public class WebAuthenticatorCDIExtension implements Extension {
> WebAuthenticator webAuthenticator;
>
>
> //I am not sure how OAuth2WebAuthenticator was discovered by openwebbeans
> but it needs to be vetoed to avoid an ambiguous dependency exception with
> the unmanaged bean below.
> void processAnnotatedType(@Observes ProcessAnnotatedType<OAuth2WebAuthenticator>
> pat) {
> pat.veto();
> }
>
> void addBeans(@Observes final AfterBeanDiscovery afb, final BeanManager
> bm) {
> afb.addBean().beanClass(WebAuthenticator.class).scope(
> ApplicationScoped.class).types(WebAuthenticator.class,
> Object.class).qualifiers(DefaultLiteral.INSTANCE).createWith(cc -> {
> return webAuthenticator;
> });
>
> }
>
> void initBeans(@Observes final AfterDeploymentValidation adv, final
> BeanManager bm) {
> //copied from JPA Extension
> try {
> final ServletContext sc = ServletContext.class.cast(bm.
> getReference(bm.resolve(bm.getBeans(ServletContext.class)),
> ServletContext.class, bm.createCreationalContext(null)));
> Meecrowave.Builder config = Meecrowave.Builder.class.cast(
> sc.getAttribute("meecrowave.configuration"));
> ResourceFinder finder = new ResourceFinder("META-INF/services/");
> Class<?> webAuthenticatorImpl = finder.findImplementation(
> WebAuthenticator.class);
> if (webAuthenticatorImpl != null) {
> webAuthenticator = (WebAuthenticator) config.getExtension(
> webAuthenticatorImpl);
> }
> } catch (Exception e) {
> adv.addDeploymentProblem(e);
> }
> }
>
> }
>
> Is there a better  way to expose extension instances to the application
> for injection? Is there a way to add other instances to the ServletContext?
>
> Regards,
>
> Aaron
>
>
> On Friday, February 2, 2018 2:18 AM, Mark Struberg <st...@yahoo.de>
> wrote:
>
>
> Hi Aaron!
>
> This sounds like extremely useful work!
> I hope you enjoyed digging into OWB and Meecrowave and of course we do
> highly welcome your contributions back to the project :)
>
> Is the code available anywhere already?
> Looking forward to work with you!
>
> @Romain incubator whould be an overkill for now I think.
> I agree that such an update mechanism might become more generic in the
> end.
> But I'd still start with it over here and then if it works fine we can
> extract it out into a component and make it more reusable.
>
> >> 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)
>
> Yes, using something like Nexus or Archiva might be perfectly fine.
> But I'd be not so quick judging before knowing Aarons exact use case.
>
>
> > 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
>
> +1
>
> > 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
>
> Yes, Maven is surely more complex than needed for just file serving.
> Otto it's a standard infrastructure item which doesn't require any
> maintenance.
> Btw re Maven: we might enhance our meecrowave-maven-plugin to package up
> and deploy such a 'release'.
> Regardless whether this is handled as attached-artifacts in a Maven repo
> or done via scp, sftp, etc.
> Again: would need to dig deeper to understand the exact need and solution.
>
>
>
> txs and LieGrue,
> strub
>
>
> > Am 01.02.2018 um 07:19 schrieb Aaron Anderson <aa...@acm.org>:
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> >
> > 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
>
>
>

Re: Desktop Meecrowave extension contribution

Posted by Aaron Anderson <aa...@acm.org>.

Hi Mark,
My experience with creating a contribution was overall positive. I did encounter a few of issues that I had to work around:
1) meecrowave.properties and CLI binding - I have several options classes that I registered as Cli.Options service loader extensions and I was able to obtain the commandline provided values without a problem. However additionally I wanted to bind meecrowave.properties values to the same options instance so I could access both the CLI values and configured values. From what I can tell the CLI values and properties are mutually exclusive, i.e. one can't override a properties file set value with a CLI value like in most apps. In any event when I tried to include my extension options in meecrowave.properties they were never available either before or after meecrowave started. I ended up creating a separate properties file and manually loading it using builder.setProperties(myProperties) and then builder.getExtension(CliExtOptions.class);
2) Add support of interfaces for extensions - I have several plugable interfaces I am using and it would have been nice to be able to register extensions instead of the extension automatically being instantiated. For example builder.addExtension(MyInterface.class,MyImplObject) and builder.getExtension(MyInterface.class) != null? .... Right now a reference to the concrete implementation class always needs to be retained to lookup an extension.
3) CDI support for objects instantiated in the extention - This was by far my biggest headache and I spent a couple of hours trying to get this to work. Basically I wanted to create a single instance of my OAuthClient that was configured via properties and have that be injectable into the running application. I wanted a configuration exactly like OWBAutoSetup,java that registers Meecrowave and it's builder as being injectable. I tried multiple attempts of adding a Tomcat listener to call the WebBeansContext.getInstance() in the right classloader with the same beanManager.addInternalBean logic but my listener was always called too late. This is where my request to allow extensions to add servletcontextlisteners originated from.

I ended up creating a CDI extension that works around the issue by leveraging the Meecrowave extension feature to lookup the configured instance:
public class WebAuthenticatorCDIExtension implements Extension { WebAuthenticator webAuthenticator;

 //I am not sure how OAuth2WebAuthenticator was discovered by openwebbeans but it needs to be vetoed to avoid an ambiguous dependency exception with the unmanaged bean below. void processAnnotatedType(@Observes ProcessAnnotatedType<OAuth2WebAuthenticator> pat) { pat.veto(); }
 void addBeans(@Observes final AfterBeanDiscovery afb, final BeanManager bm) { afb.addBean().beanClass(WebAuthenticator.class).scope(ApplicationScoped.class).types(WebAuthenticator.class, Object.class).qualifiers(DefaultLiteral.INSTANCE).createWith(cc -> { return webAuthenticator; });
 }
 void initBeans(@Observes final AfterDeploymentValidation adv, final BeanManager bm) { //copied from JPA Extension try { final ServletContext sc = ServletContext.class.cast(bm.getReference(bm.resolve(bm.getBeans(ServletContext.class)), ServletContext.class, bm.createCreationalContext(null))); Meecrowave.Builder config = Meecrowave.Builder.class.cast(sc.getAttribute("meecrowave.configuration")); ResourceFinder finder = new ResourceFinder("META-INF/services/"); Class<?> webAuthenticatorImpl = finder.findImplementation(WebAuthenticator.class); if (webAuthenticatorImpl != null) { webAuthenticator = (WebAuthenticator) config.getExtension(webAuthenticatorImpl); } } catch (Exception e) { adv.addDeploymentProblem(e); } }
}
Is there a better  way to expose extension instances to the application for injection? Is there a way to add other instances to the ServletContext?
Regards,
Aaron 

    On Friday, February 2, 2018 2:18 AM, Mark Struberg <st...@yahoo.de> wrote:

 Hi Aaron!

This sounds like extremely useful work!
I hope you enjoyed digging into OWB and Meecrowave and of course we do highly welcome your contributions back to the project :)

Is the code available anywhere already?
Looking forward to work with you!

@Romain incubator whould be an overkill for now I think.
I agree that such an update mechanism might become more generic in the end. 
But I'd still start with it over here and then if it works fine we can extract it out into a component and make it more reusable.

>> 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)

Yes, using something like Nexus or Archiva might be perfectly fine.
But I'd be not so quick judging before knowing Aarons exact use case. 

> 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

+1

> 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

Yes, Maven is surely more complex than needed for just file serving. 
Otto it's a standard infrastructure item which doesn't require any maintenance.
Btw re Maven: we might enhance our meecrowave-maven-plugin to package up and deploy such a 'release'.
Regardless whether this is handled as attached-artifacts in a Maven repo or done via scp, sftp, etc.
Again: would need to dig deeper to understand the exact need and solution.

txs and LieGrue,
strub

> Am 01.02.2018 um 07:19 schrieb Aaron Anderson <aa...@acm.org>:
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 
> 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

Re: Desktop Meecrowave extension contribution

Posted by Mark Struberg <st...@yahoo.de>.

Hi Aaron!

This sounds like extremely useful work!
I hope you enjoyed digging into OWB and Meecrowave and of course we do highly welcome your contributions back to the project :)

Is the code available anywhere already?
Looking forward to work with you!

@Romain incubator whould be an overkill for now I think.
I agree that such an update mechanism might become more generic in the end. 
But I'd still start with it over here and then if it works fine we can extract it out into a component and make it more reusable.

>> 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)

Yes, using something like Nexus or Archiva might be perfectly fine.
But I'd be not so quick judging before knowing Aarons exact use case. 


> 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

+1

> 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

Yes, Maven is surely more complex than needed for just file serving. 
Otto it's a standard infrastructure item which doesn't require any maintenance.
Btw re Maven: we might enhance our meecrowave-maven-plugin to package up and deploy such a 'release'.
Regardless whether this is handled as attached-artifacts in a Maven repo or done via scp, sftp, etc.
Again: would need to dig deeper to understand the exact need and solution.



txs and LieGrue,
strub


> Am 01.02.2018 um 07:19 schrieb Aaron Anderson <aa...@acm.org>:
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 
> 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