openwebbeans-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject Re: Desktop Meecrowave extension contribution
Date Fri, 02 Feb 2018 20:03:12 GMT
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 <aaronanderson@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 <struberg@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 <aaronanderson@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
> 
> 


Mime
View raw message