Mw extension ;) Le 2 févr. 2018 21:03, "Mark Struberg" <[email protected]> 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 <[email protected]>: > > > > 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 <[email protected]> > 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 <[email protected]>: > > > > > > 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 > > > > > >
